On Mon, May 19, 2008 at 09:40:09PM +0000, Stefano Zacchiroli wrote: > On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote: > > > You're describing a situation where upstream is difficult or impossible > > > to communicate with. I can't solve that, nor can anyone except upstream. > > > > Except that once again, upstream that would benefit from our system > > the most are those kind of upstreams, with very large sources, huge user > > base, huge bugs lists, and massive amounts of patches floating around. > > This does not imply that such upstreams (which I agree are those who > would benefit most from the improvements being discussed) are using > systems hard to communicate with. > > I get your word that KDE and glibc are in such a category, but we need a > bit of numbers before concluding that "large packages" implies "sucky > BTSs". Do you perhaps have some kind of evidence of this from bts-link? > (If this is so, it wasn't clear to me from the post I'm replying to.) It does not implies such a thing, it's not even a hard rule, though it's common enough. KDE uses a huge BZ, Gnome does too, mozilla does too, xorg does too, linux also has a BZ (even if I'm not sure it's the preferred form of bug reporting, it's quite unclear depending on the submodule), gcc, binutils and most of the toolchain packages have a BZ (on sourceware.org), OOo has an issuezilla (which is a BZ in disguise), … Of course, vim uses a mailing list, TTBOMK emacs does too. You can have a look by yourself, the current list of BTSes bts-link knows about is here: http://git.debian.org/?p=bts-link/bts-link.git;a=blob;f=btslink.cfg;hb=HEAD The sole decent BTS here is trac, that allow to report bugs in one form only, no auth (except HTTP), no intermediate form, no nothing. I've had to use every of the other ones (except mantis) and none are efficient for reporting bugs massively like maintainers with thousands of bug should do. Of course, bts-link don't know every BTS out there, bug it's fair to assume I've been contacted by maintainers that find that dealing with their upstream's BTS is a PITA (else they wouldn't have bothered sending me a mail probably). Anyways, my point is that we should not really focus on how to "track" patches, but how to ease reporting bugs/patches upstream, in a unified _simple_ way. The current discussion is built on sand: Joey's proposal stands on the assumption that maintainers do open bugs upstream for each patch they have in their package. That isn't true, and for a good reason: for many upstreams, this is way too long. Speaking from experience, when I work on a Debian package, reason says that I should only spend 30 minutes on it. 45 minutes later I'm still on it, and well, when the patches I've written have to go to a BZ, I just don't forward them because I'm already 15 minutes late, and that it's a one minute story per patch. I just don't have that time for -15 minutes already. When upstream uses a Mailing list, or anything where I can submit patches sending a mail, it's merely a git-format-patch | mail, which is 3 seconds away, and I do it. And it's enough because my patches are commented. Is it bad behavior ? Yes, it is. But that's the way it is, and I would be more than surprised to be an isolate case. Just write a damn tool that allow forwarding bugs with a unified _optimized_ (ergonomics-wise) fashion, and tadaaa you'll see that many things will be way simpler, and that we won't even need joey's proposal at all, or only for very seldom cases. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpOMtPamIXV_.pgp
Description: PGP signature