[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 18/05/08 at 16:44 +0100, Neil Williams wrote:
> 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 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

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?

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

> Going back to the original message:
> http://lists.debian.org/debian-devel/2008/05/msg00536.html
> "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."

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.
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Attachment: signature.asc
Description: Digital signature

Reply to: