Hi, On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote: > > - 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? > > Please don't. It would be Really Troublesome should a package need to > switch from native to non-native, or the opposite.
Why? Until we have defined what the layout is for a native package, you can't assume this. It's possibly a subset of the conventions for non-native packages + some common conventions in all software projects. Something like: - branches - master: main development branch - <vendor>/<codename>: only for downstreams (not Debian which is upstream) - tags - <version>: release tags - <vendor>/<version>: only for downstreams > If you're worried about an useless "master" branch, one can do away with it > with help of git symbolic-ref on bare repositories: > > git symbolic-ref HEAD refs/heads/debian/master > > will change a bare repo's default branch to "debian/master", you can remove > the "master" branch after that. That's a good idea anyway. > > - are there other important things to standardize? > > What to do with packages that already adopt other schemes? A lot of > packages already use dgit, git-buildpackage, etc and have signed tags they > might want to preserve. Ideally, once we have clear conventions, the various tools start to use the new conventions. That said I don't see the need to rename all past tags. But if enough people feel that such renames are useful, I'm sure the operations can be scripted and integrated in new versions of the various tools. > Also, tag namespace is shared with upstream, so it has to be somewhat > flexible in case the recommended scheme cannot be used. That's one of the reason why we use a prefix. Do you have a concrete example of when it could be problematic? The only problematic case I can think of is when upstream already has a "debian" tag. > Release tags ought to always be signed really, Yes. > but should we recommend something about commits or just ignore that? I have no opinion on this and I have never done this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140816195205.gk13...@x230-buxy.home.ouaza.com
