On Tue, 11 Nov 2014, Barry Warsaw wrote: > One question: when this gets adopted, will individual maintainers or teams > have to know which of the git packaging helpers a particular repository is > using? IOW, what happens if I were to use gbp-pq on a package that someone > else had used git-dpm on? Do we need some kind of convention to detect which > helper is being used? I wouldn't want to restrict choice by defining a > standard Debian-wide (but it's okay within the context of a team). I just > want someone who walks up to a git repo to at least easily know which tools to > use.
I don't know. My long term hope is that in this process we will get to a situation where: - either the tools are sufficiently interoperable that we don't have to care about this - or one of tools emerges as standard supporting all the important workflows that people are using > >Each "vendor" uses its own namespace for its packaging related > >Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and > >so on. > > My question is whether the vendor namespaces are overkill for the majority of > packages, where there probably will be just one vendor (i.e. Debian). Should > DEP 14 allow for a simplified layout such as master, pristine-tar, upstream > when there is no other vendor involved? Allowing for master as an alternative > to debian/sid or debian/master might simplify the common case. I am rather opposed to this because it because it doesn't separate clearly the namespaces for the upstream development and the namespace for the Debian packaging. Even when upstream doesn't use Git, you never know whether this won't change at some point and while it's perfectly possible to rename branches when needed, this operation is not something that is tracked in any way in the git clones that all users might have (it's really a branch deletion + a new branch) so local configuration about which branch is tracked is now broken and you have no safeguard against non-fast-forward change at the time you rename the branches, and so on. I really believe that always using the prefixed namespace is the correct course of action. > for the current Ubuntu development series. If I needed to support older > releases in either distro, then debian/wheezy or ubuntu/utopic would be good > branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) I was wondering that as well. For Ubuntu, it probably makes sense to use ubuntu/master because the latest development release regularly changes and it's not a good idea to alway update the branch. So that is one reason more to allow usage of `<vendor>/master` as a packaging branch. > >If the Git workflow in use imports the upstream sources from released > >tarballs, this should be done under the "upstream" namespace. By default, > >the latest upstream version should be imported in the `upstream/latest` > >branch and when packages for multiple upstream versions are maintained > >concurrently, one should create as many upstream branches as required. > > Similarly, is 'upstream' okay for the upstream branch? It's a little simpler > than upstream/latest, especially if you don't anticipate importing an other > upstream branches. And it's also compatible with the current gbp practice. I'm not set of upstream/latest but given what I said above about renaming branches, I still believe that it's best to have a default name that does not need to be renamed when you want to add more upstream branches. Or maybe we recommend "upstream/latest" by default but allow "upstream" alone in the case when there are no other upstream branches tracked ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112090254.gd27...@home.ouaza.com