[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 17:05 +0200, Lucas Nussbaum wrote:
> On 18/05/08 at 16:27 +0200, Bas Wijnen wrote:
> > 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.
> Ah, interesting. We are not trying to solve the same problem, which
> might explain why it's so hard to converge to a single solution.
> 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 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

Going back to the original message:

"The BTS could be enhanced to allow opening a bug and forwarding it
upstream in a single message. (IIRC currently, it takes two). This would
allow a very simple workflow where a DD makes a change to a package,
generates a patch, and sends it upstream while also recording the
divergence in the BTS."

To me, that reads as:
Use the upstream trackers to let upstream people know which patches we
applied and why. Use the BTS to track the Debian side of the divergence.

(Every divergence has two sides, otherwise there would be no difference
between Debian and upstream.)

I'd like to see that extended to include:
Use tags in the BTS and custom webpages to let others know which bugs we
fixed with these patches. If the upstream tracker isn't public, file the
patches in the BTS too so that everyone can find it. 

Then, when an upstream release finally includes the effect of the patch,
remove the patch from Debian and change Fixes: to Closes:.

What this proposal is about is identifying where Debian has diverged
from upstream so that it is easier for Debian to get back into sync with
upstream, not for upstream to get into sync with Debian. (Subtle

You appear to want upstream to come to us and for us to provide
one-tracker-to-rule-them-all to suit the needs of every upstream team
with a Debian package. That isn't going to happen.

I want Debian to go to upstream (as now) and let DD's suffer the hassle
of divergent upstream bug trackers so as to not force that workload on
our users or members of different upstream teams trying to work out why
their code is suffering from a buggy -dev package. If appropriate, feed
that info into the BTS.

Users can choose whichever bug tracker they prefer - the Debian BTS or
the upstream bug tracker for the project concerned. It is up to Debian
to ensure that proper use of Forwarded ensures that the same information
is available via (but not necessarily in) both. i.e. whichever entry
route is chosen, links are available to go to the relevant point where
the information is publicly available (without logins). Whether that
particular point is in the upstream bug tracker or the BTS is
inconsequential. The essential point is that it does exist and it is
linked from both entry points.

Upstream have chosen their bug tracker and whether we like it or not,
they are unlikely to migrate to one that Debian devises. That way lies
Launchpad. Yuck. As an upstream myself, I simply refuse to use that
horror. There again, I would also refuse to use the RH or Fedora bug
trackers or the OSX bug trackers or Fink or BSD or who knows what else.
As upstream, I've settled on the bug tracker I want to use upstream (and
in some cases it is the BTS) and I'm not going to go trawling round the
distros myself. I want the distros to come to me - as the BTS currently
does via Forwarded and the Fedora people do via their methods. I've
clearly documented the preferred bug tracker for each project on the
relevant website for that project.

The BTS cannot be all things to all people and I fail to see that Vcs
solves anything with regard to divergence (it only provides history, not

With or without a README.source, Vcs does nothing to help me track which
patches that I have applied in Debian are actually diverging from
upstream and which have been applied. To find that out, I need to build
the package and see the failure messages from patch. Not ideal.

This way, I can indicate to the bug submitter that the bug is fixed in
Debian (using a divergence) by including (Fixes: #1234) in a new Debian
revision. Until the bug is fixed in an upstream release, I still see
that the package has bugs that are Fixed but not Closed. bts-link takes
care of updating the tags on the Fixed bugs (because they are also
forwarded) so that when the upstream release is made, I know which
patches are included upstream. I can then remove those patches, build
the new upstream release, implement any new divergences if needed and
upload with (Closes: #1234).


Neil Williams

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

Reply to: