On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote: > - how do we tag the package releases? > > - pkg/<version> > (note: git-buildpackage uses debian/<version> but I find this confusing > as we then also have the "debian/" prefix for ubuntu or kali uploads, we > don't need the vendor prefix as the usual versioning rules embed the > downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be > any conflict on the namespace, keeping a prefix is important to easily > differentiate tags created by upstream developers from tags created > by packagers) Letting aside the fact that "pkg/..." looks really ugly IMO, you are breaking backwards "compatibility" with most git-buildpackage repositories for no real benefit. If adopting this policy means that I have to somehow convert all my repositories (possibly losing mildly useful information such as tag creation date, tagger identity, tagger gpg signature, etc...), I'm not gonna do it. Yes, if someone uses "debian/..." for e.g. ubuntu tags too (or uses some other tag naming scheme), they'd have to change them, but I think it would be a much smaller subset of both repositories and tags within a repsoitory. Obviously one wouldn't be forced to convert their repositories to be compliant to this policy, but if e.g. tooling based on this proposal is developed for extracting information from repositories, and if there are very few repositories actually compliant because it's too much of a PITA to convert, it's all gonna be pretty useless. Additionally, using the <vendor>/<version> scheme would allow for very simple enumeration of debian vs. ubuntu vs. other with something like "git tag | grep ^<vendor>/" without the need to actually parse debian/changelog or the specific version of the tag (dunno if this would actually be useful for anything, but it's a possibiliy). Also, does every downstream distribution actually embed the distribution name in the upload version or is it just ubuntu? Do they use the same scheme? Would it be ok for this policy to "depend" on this? > - where should the HEAD point to in the public repository? Not sure what you mean by this. > - shall we standardize the "pristine-tar" branch? While I use pristine-tar, I feel like it's more of an implementation detail of the building tools for the "how to generate the orig tarball" problem, than something that should be standardized. Also FWIW, pristine-tar is orphaned (see #737871, which contains some reasoning about why using pristine-tar may not be a good idea). > - the above layout is for the traditional case of non-native packages, > what would be the layout for native packages? how can be differentiate > between native/non-native layout? I've never maintained a native package so I don't really know what are the common practices, but AFAICT the only difference would be missing "upstream/..." tags. Would that be enough for differentiating them? > - are there other important things to standardize? GPG signatures for tags? Although, I'm not sure if mandating signing tags would be a good idea. Cheers
Attachment:
signature.asc
Description: Digital signature