FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-17-2008, 09:01 PM
Joey Hess
 
Default divergence from upstream as a bug

What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite naturally..

The bug can be tracked, with a patch, in our BTS. The bug can be
forwarded upstream as the patch is sent upstream. A tag "divergence" can
be used to query for all such bugs, or to sort such bugs out of the way.

Other tags and BTS data can be used if desired. For example, "divergence
fixed-upstream", "divergence wontfix", "divergence help". Versioning
information can be used to track when an upstream version resolves the
divergence. Discussion and updated patches can be CCed to the bug log.

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.

There would also be scope for other workflows, as well as automated
tools. If a package has a debian/patches, some of which have been
forwarded upstream and some not, then a tool could query the BTS (or
headers in the patches, whatever) to figure out which have yet to be
sent upstream, and send them. Tools could also do this for changes
recorded in a VCS.

For QA, a tool could compare the divergences recorded in the BTS with
the source of the package and warn developers about unrecorded
divergences, and divergences whose patch doesn't appear in the package's
source (due to the patch being accepted upstream, or being changed after
being sent to the BTS).


For all the maintainers who already keep on top of forwarding their
changes upstream, this won't be much of a burden; ideally you just CC
the BTS and add some pseudoheaders. For ones who can't, because they
cannot communicate with upstream (for whatever reason), it gives them a
way to communicate with other interested parties (users, other distros)
and maybe resume communication with upstream in the future. Maintainers
who make more patches than they have time to send to upstream will have
a problem, and might get other people filing bugs against their package
about that, which actually helps them deal with the problem. It seems a
win-win all the way around.

Of course it means that every package is insta-buggy, but we can deal
with getting those bugs recorded piecemeil[2]. Looking over my packages, I
think I could get all their current divergences recorded in the BTS within
the week. (And if it would help to have a concrete example of this proposal,
I volenteer to do that.)



PS, I don't want to give the wrong impression: I don't think that this
would have avoided the openssl disaster, and this email is not a
reaction to that.

--
see shy jo

[1] Specifically, changes outside debian/, and changes inside debian/
that result in the upstream source being patched, or add stuff
like man pages that should really be added upstream.
[2] Or attempt to win Bubulle's contest by filing them all now, also
fine by me.
 
Old 05-17-2008, 09:08 PM
Pierre Habouzit
 
Default divergence from upstream as a bug

On Sat, May 17, 2008 at 09:01:08PM +0000, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug?

WTF ? What's the point of free software if we invent rules for not
modifying them ? And well, we're in a bad posture then, because glibc
without patches can't work. Striving for minimal differences is good,
but deciding a change is a bug ? please…

--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
 
Old 05-17-2008, 09:11 PM
Mike Hommey
 
Default divergence from upstream as a bug

On Sat, May 17, 2008 at 05:01:08PM -0400, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite naturally..
>
> The bug can be tracked, with a patch, in our BTS. The bug can be
> forwarded upstream as the patch is sent upstream. A tag "divergence" can
> be used to query for all such bugs, or to sort such bugs out of the way.
>
> Other tags and BTS data can be used if desired. For example, "divergence
> fixed-upstream", "divergence wontfix", "divergence help". Versioning
> information can be used to track when an upstream version resolves the
> divergence. Discussion and updated patches can be CCed to the bug log.
>
> 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.
(...)

The BTS would also need something to make it easier to spot patches in a
bug. Patch tracking is one of the few things bugzilla is not bad at, for
instance.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 05-17-2008, 09:12 PM
Loc Minier
 
Default divergence from upstream as a bug

On Sat, May 17, 2008, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.

The bug tracker is a tool for me; not everything needs to go via bug
tracking. If I grab an upstream change from their VCS, I wont open a
Debian bug about it; if I find a bug in the Debian version which also
applies to upstream, I might skip to directly reporting it upstream,
and only there.

A change is a change, not a bug; we don't need to map each change to a
bug. We could get better at distinguishing between changes, and
perhaps we can reach a point where we can extract a list of logical
changes (or changesets) between Debian uploads, or between the Debian
and upstream versions, but I don't think we want bugs for that.

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 05-17-2008, 09:13 PM
Mike Hommey
 
Default divergence from upstream as a bug

On Sat, May 17, 2008 at 11:08:06PM +0200, Pierre Habouzit wrote:
> On Sat, May 17, 2008 at 09:01:08PM +0000, Joey Hess wrote:
> > What if we just decide that changes made to upstream sources[1] qualify
> > as a bug?
>
> WTF ? What's the point of free software if we invent rules for not
> modifying them ? And well, we're in a bad posture then, because glibc
> without patches can't work. Striving for minimal differences is good,
> but deciding a change is a bug ? please…

You should read after the first sentence.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 05-17-2008, 09:21 PM
Joey Hess
 
Default divergence from upstream as a bug

Mike Hommey wrote:
> The BTS would also need something to make it easier to spot patches in a
> bug. Patch tracking is one of the few things bugzilla is not bad at, for
> instance.

I guess you're talking about a way for the BTS allow downloading of the last
(or preferred) patch sent to a bug. And not just deciding when to set
the "patch" tag. That would be useful for the QA tool that checks if
divergence's patches match the debianised source. Dunno if it's
mandatory, the tool could also use heuristics, or try every attachment
that looks like a patch and see which, if any, match.

--
see shy jo
 
Old 05-17-2008, 09:22 PM
Pierre Habouzit
 
Default divergence from upstream as a bug

On Sat, May 17, 2008 at 09:13:03PM +0000, Mike Hommey wrote:
> On Sat, May 17, 2008 at 11:08:06PM +0200, Pierre Habouzit wrote:
> > On Sat, May 17, 2008 at 09:01:08PM +0000, Joey Hess wrote:
> > > What if we just decide that changes made to upstream sources[1] qualify
> > > as a bug?
> >
> > WTF ? What's the point of free software if we invent rules for not
> > modifying them ? And well, we're in a bad posture then, because glibc
> > without patches can't work. Striving for minimal differences is good,
> > but deciding a change is a bug ? please…
>
> You should read after the first sentence.

Okay, still I dislike the idea a lot. the BTS is unusable past 100
bugs. For some packages this will add 100 more, that will never go away.
And upstreams wont want to use yetanother bug tracker, they want to use
theirs (especially the ones using RT or BZ that ensure this way never to
recieve too many patches… *cough*).

--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
 
Old 05-17-2008, 09:22 PM
Neil Williams
 
Default divergence from upstream as a bug

On Sat, 2008-05-17 at 23:08 +0200, Pierre Habouzit wrote:
> On Sat, May 17, 2008 at 09:01:08PM +0000, Joey Hess wrote:
> > What if we just decide that changes made to upstream sources[1] qualify
> > as a bug?
>
> WTF ? What's the point of free software if we invent rules for not
> modifying them ?

? AFAICT the point is that we feed those changes back to upstream
instead of hoarding them in the current layers of Debian changes. I
think it's a good idea.

> And well, we're in a bad posture then, because glibc
> without patches can't work.

And what is it that makes this not a bug in upstream glibc? I know it is
a complex build but that only makes it more important that the Debian
changes are clear and unambiguous. glibc and gcc are the most complex
packages that I regularly build (ok, crossbuild) and I dread seeing the
email from incoming that a new version needs to be prepared for Emdebian
because it nearly always fails first time, despite working last time.

> Striving for minimal differences is good,
> but deciding a change is a bug ? please…

I think it is right that a change is a bug - after all, Debian builds on
a range of architectures that upstream often do not have available. When
upstream does not build on these architectures, that is a portability
bug upstream. It would catch out someone upstream if they were to try
and build the package on that arch so why not post the fix to the
upstream bug tracker?

Call it a feature enhancement if you like but it still ends up in a bug
tracker of one kind or another so might as well call it a bug IMHO.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 05-17-2008, 09:31 PM
Pierre Habouzit
 
Default divergence from upstream as a bug

On Sat, May 17, 2008 at 09:22:53PM +0000, Neil Williams wrote:
> email from incoming that a new version needs to be prepared for Emdebian
> because it nearly always fails first time, despite working last time.

welcome to our (mostly Aurlien's) world, because if you see the
revisions, you'll know that's the same for stock Debian as well.

> Call it a feature enhancement if you like but it still ends up in a bug
> tracker of one kind or another so might as well call it a bug IMHO.

The BTS is not well suited for that, so we're back to discussing about
which tool is best for doing that, as discussing how to do that in the
source package failed, we go to the BTS.
--
O Pierre Habouzit
O madcoder@debian.org
OOO http://www.madism.org
 
Old 05-17-2008, 09:34 PM
Mike Hommey
 
Default divergence from upstream as a bug

On Sat, May 17, 2008 at 05:21:52PM -0400, Joey Hess wrote:
> Mike Hommey wrote:
> > The BTS would also need something to make it easier to spot patches in a
> > bug. Patch tracking is one of the few things bugzilla is not bad at, for
> > instance.
>
> I guess you're talking about a way for the BTS allow downloading of the last
> (or preferred) patch sent to a bug. And not just deciding when to set
> the "patch" tag. That would be useful for the QA tool that checks if
> divergence's patches match the debianised source. Dunno if it's
> mandatory, the tool could also use heuristics, or try every attachment
> that looks like a patch and see which, if any, match.

I'm not only talking about tools. It's also suboptimal for humans to
spot patches in several pages of history. It would be best to have links
to patch in the top part of the bug page.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 12:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org