On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote: > But the problem we want to solve is making things easier for > upstreams.
Oh? When I read the proposal, I understood that the problem we want to
solve is about tracking changes we make to upstream. If upstream wants
those changes, there is nothing to track. So it's not about helping
upstream, it's about helping others who may be interested in our
changes. Such people may be NMUers, or other distribution's packagers,
for example.
> > > What Joey's proposal is:
> > > * put more burden on the maintainers that already report patch
> > > upstream ;
> >
> > Are these maintainers not recording the fact of a bug in the BTS?
>
> When it's fixed in Debian ? What's the point ?
They have already reported the issue as a bug, if they did things right,
and they close that bug with their change. In other words, they're
interacting with the BTS already anyway.
In fact, it could be a good idea to let this BTS interaction work
through debian/changelog as well, similar to closes: #123456. (It
should of course be able to open bugs as well.)
The point is that this information is worth tracking, and the BTS is a
technical system which is very capable of doing so. A bug in the BTS
doesn't mean that there is something that needs fixing. Already it
doesn't, which is why we have the WONTFIX tag. This just adds another
category of bugs which may or may not need fixing.
The benefit is not that the number of changes will be minimized due to
people trying to get the BTS empty[1]. The benefit is that things are
nicely documented and trackable.
Also, all the extra work you see is minimal IMO. We're talking about
the situation where the maintainer will be writing code and testing the
changes. This takes something like half an hour, minimum. Then a good
maintainer will inform upstream about this, which takes about 5 minutes.
Most upstreams will be reached using e-mail (a mailinglist, usually).
In that case, adding the Cc: and pseudo-headers takes less than a
minute. If they don't have e-mail, sending one to the BTS takes perhaps
two minutes. This is really not significant compared to the task it is
added to.
I don't see your problem.
Thanks,
Bas
[1] Just to plug in one of my favorite subjects: IMO if the maintainer
disagrees with upstream about how to fix something, it is good that
the maintainer will make the changes (which are then not
incorporated upstream). So in those cases, I would be against
"fixing" those bugs by dropping the patches.
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
