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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote:
> > > The problem I am interested in solving is:
> > >   It is currently difficult for people not involved in Debian
> > >   development (upstream, other distros, users) to know which patches we
> > >   applied, the reason for the patch, and whether they should be
> > >   interested in that patch or not.
> > 
> > In that case, the fault lies in Debian for not using Forwarded properly.
> > IMHO we should be going out of our way to communicate with upstream
> > using the systems preferred BY upstream, not trying to devise a new one.
> > 
> > I know it's a PITA using bugzilla and a gazillion different logins but
> > that is part of the workload.
> I think that upstreams would like two different things:
> - that distros forward patches to their BTS
> - that distros provide an automated, simple way to see what they patched

ok - so two problems, not one.

> That sounds logical to have both:
> - they know that distro devs are not perfect and sometimes don't forward
>   simple patches
> - they want to know which patches are actually used (and widely tested),
>   because that make them better candidates for integration upstream

> But maybe I'm just misunderstanding upstreams' needs?

There's no accounting for the variety in upstream teams - I don't know
many that want the second option but I can see that some will probably
want it that way, if only because of an MIA DD.

> > > I thought that the problem of tracking changes for Debian developers was
> > > already solved by using a VCS and advertising it thought Vcs-*?
> > 
> > No, it isn't because Debian developers still need to track where Debian
> > patches have diverged from upstream due to delays in upstream
> > development. Vcs does nothing for that, nothing whatsoever (and I
> > consider it a nonsense to include the entire upstream codebase in our
> > RCS).
> If we have a Formarded-upstream: field in patches.d.o (pointing to the
> upstream bug for a patch), it would be easy to modify bts-link and
> automatically monitor those upstream bugs.

I still like the two-stage closure option because sometimes we just need
to upload a fix before an upstream release can be made and the bug
submitter should know that the bug has been fixed using a divergence
whilst still waiting for upstream.

> Yes. One problem with this discussion is that we are discussing:
>    What can/can't we do by using, abusing and modifying our current
>    infrastructure (i.e the BTS)?
> Instead of discussing:
>    What is the real problem that we are trying to solve? What needs
>    to be done to fix that problem? (what features/requirements are
>    needed in a candidate solution?)
> The discussion is polluted by technical details about BTS things, and
> this hides the real issues.

OK, so problem 1:
Q: How to improve Debian forwarding patches to upstream using upstream
bug trackers?
A: Leave the burden on the DD to handle multiple logins to multiple bug
trackers but make life easier in the BTS so that everyone can read the
patch without needing a login. This, IMHO, is met by the Fixed|Closed
two stage closure idea.

Problem 2:
Q: How to help upstream find out from Debian which patches are actually
in use.
A: provide browsable patch files organised by source package (the
upstream source package name if it differs) - this sounds like the
patches.d.o idea.

I'll stick to Problem 1. :-)

I think you're right that there are two distinct problems - although I'm
still not convinced that Problem 2 is sufficiently common to require a
whole new bug/patch tracker.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: