On Sun, Jan 08, 2012 at 09:50:32AM -0800, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > > I object to policy specifying any Vcs-* fields in a way that does not > > uniquely identify a Debian packaging branch. Running debcheckout for a > > package only to then have to guess at random which of 20 branches is the > > one containing the packaging I care about[1] is nonsense, and I don't > > think this has any business being in policy in the absence of sensible > > semantics. The field should in all cases point to the right branch, not > > just the right repository, and in the absence of an acceptable > > per-branch URI syntax, it ought not be standardized at all. > > While I'm sympathetic to this position, the concern that I have with going > this route is that "what branch I care about" is never going to be a > clearly-defined concept. Is it the branch for unstable? The latest > packaging, which may only be in experimental, or may not have been > uploaded at all? Are you working on a stable update, in which case you > need another branch entirely? I have to agree with Russ here. It's easy enough to change the Vcs-* fields so they're appropriate for uploads to unstable or experimental, but as soon as a package transitions out of unstable the field is potentially out of date. If there's a non-trivial branching policy, then that could be described in README.source (or a new README.vcs since it's not directly related to working with the source package). This is more relevant for non-DVCS (like svn) since checking out an entire project's repository instead of just the development branch can take much more time and space. The problem is that the exact VCS where it is most beneficial to provide the most specific information are also the ones where not having the correct information (e.g., still having the URL for unstable when the package is in stable) makes the checkout useless. > > Now, given that git seems to be the only widespread VCS with theis > > problem, I wouldn't object to codifying Vcs- fields for the others in > > the meantime; but some people might find it equally unpalatable to > > specify fields for everything except git. Any VCS workflow which uses different branches for different releases (or uploads to places other than unstable) is going to have this problem. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@debian.org>
Attachment:
signature.asc
Description: Digital signature