On Sat, May 17, 2008 at 05:04:56PM +0000, Manoj Srivastava wrote: > On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> said: > > > > (publishing my branch in a gitweb) isn't normalized, and won't > > probably ever be, or not under this form. > > Don't you think that Vcs-Browse and Vcs-$SCN headers are > normalized ways for telling end users where to get the development > sources from?
For devel sources yes. Sadly, this won't give you the straight URL to
what upstream are interested in.
> We might want to see if we should shipt the VCS-* headers
> in the Packages file, but I thought we are trying to standardize
> publication of DVCS repositories in Debian now.
Well, that's not needed, that could be really easily used in a
patches.d.o service like Vincent is asking for. Though even with VCS-*
headers, it's still hard to _automatically_ present things coherently
enough for automated tools to do some useful reports. OTOH such tools
could be written for each VCS< there aren't _that_ many of them (I mean,
compared to the number of bug-trackers out there, bts-link showed such a
task is doable). but again, even grokking the VCS isn't enough, you'll
have to know where the maintainer put things in the first place. ANd
here, grokking git isn't enough. *I* don't even use the same name for
all my packages, I don't expect it to be more coherent for _different_
packagers.
All in all, pointing to VCSes is just making things harder, because
you fight against direct product of VCSes, workflows, and almost
packages. And no tool is really gonna sort that out. OTOH, if we _do_
mandate people to one way or another serialize their patches in the
source format, with comments and all that stuff, then it _IS_ a good
thing, because that's the kind of things that can be grokked by tools
trivially. And for that, the v3 format goes in the proper direction.
I think people want to solve many problems, that happen to coincide
locally, but are quite different in the end. I see three of them:
* how to have packages that everyone can modify for NMUs and security
updates, where it's obvious to anyone what the packager did. I know
_you_ don't care about that [citation needed -- but it's not hard to
find ;p] but I think it's a very important goal.
* how to let upstreams be able to know what we do to their babies,
even when we don't have time (or are too lazy to fight against the
128 steps needed to submit a damn patch in their bugzilla[1]) to
send patches back, be able to see what we didn't sent yet easily,
and automatically (and with a finer grained method than the .diff.gz
please).
* maintaining history of the patches, and how to they evolve for
long-lived patches. Which is a discussion that generates long
tro^H^H^Hfla^H^H^Hdiscussions on the vcs-pkg list.
Too many people are in fact only considering the (3rd) issue because
that's clearly the one that is mind challenging and I'd even say
interesting. Though, sorry to try to try (I don't really think _you_'ll
agree ...) to bring you back to earth, but the 1st and 2nd points are
the utterly important ones, by far. How do we have nicer histories in
our VCSes is just clever and twisted bikeshedding (that I'm clearly
happy to participate in, because I'm a pervert and I like that), but
it's not what matters. What matters for real, is how simple it is for
other DD to fix our packages when we're absent, or when we don't want to
maintain a package anymore, and how easy and automatic collaboration
with upstream is. The VCS rebase vs. merge vs. patch queues vs. diff.gz
discussions are just cherry on the top.
[1] FWIW that's exactly what often makes me "forget" about reporting a
patch. Bugzilla really really really sucks badly for the reporter,
the Debian BTS is _way_ better in that regard.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgptiQvAXwrv6.pgp
Description: PGP signature
