Currently, the debian/<version> git tag namespace is used by a number of different tools, and can mean different things in different packages and sometimes even different things for the same package in different repos or trees.
dgit produces, and the dgit git server requires, tags of this form, which refer to the dgit branch, which is roughly what some people call a `patches-applied packaging branch'. So far, dgit has been using debian/<version> for this. But this is a problem because this tag namespace is used for other purposes and has no clear meaning. I'm currently working on dgit native push support for users of 3.0-quilt+git-buildpackage, where this is particularly bad because it would involve dgit making two tags with the same name (!) Having considered things, I think it would be best for dgit to concede this area of namespace for all the existing uses. Declaring those existing uses wrong, just because they're varied and and mutually inconsistent, is not very helpful. Consequently I need a new namespace. I don't want to put `dgit' in the name because the format is not specific to dgit. It is simply the result of `dpkg-source -x' (only without the .pc directory which dpkg-source sometimes produces). I am currently thinking that dgit would start to use the tag namespace Debian/<version> instead. These tags would always refer to a Patches-applied packaging branch (where applicable containing a patch to add or update .gitignore). For other distros, I would likewise capitalise just the first character of the distro name (with `ucfirst' in Perl). So `Ubuntu/<version>'. <version> is translated as specified in DEP-14. So this message is: * A request for anyone to say if they know of a reason I shouldn't do this. * A declaration (currently, tentative) of intent to claim this part of the git tag namespace. * A proposal to update DEP-14 to declare that "vendor" in DEP-14 should start with a lowercase letter, and ideally, to reserve the corresponding starts-with-uppercase tags for dgit. Thanks, Ian.
