[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: divergence from upstream as a bug

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:
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

  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

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpCVJIpdJNA2.pgp
Description: PGP signature

Reply to: