divergence from upstream as a bug

classic Classic list List threaded Threaded
196 messages Options
1234 ... 10
Reply | Threaded
Open this post in threaded view
|

divergence from upstream as a bug

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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Pierre Habouzit-5
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                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Mike Hommey
In reply to this post by Joey Hess
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Loïc Minier-3
In reply to this post by Joey Hess
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.

--
Loïc Minier


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Mike Hommey
In reply to this post by Pierre Habouzit-5
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Joey Hess
In reply to this post by Mike Hommey
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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Pierre Habouzit-3
In reply to this post by Mike Hommey
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                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Neil Williams-4
In reply to this post by Pierre Habouzit-5
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/



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Pierre Habouzit-3
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 Aurélien'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                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Mike Hommey
In reply to this post by Joey Hess
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Joey Hess
In reply to this post by Loïc Minier-3
Loïc Minier wrote:
>  The bug tracker is a tool for me; not everything needs to go via bug
>  tracking.

I'm not thinking about using the BTS for this just because it happens to
be the hammer at hand, but instead because it looks to be a tool that
allows solving a large percentage of the requirements, and already
interoperates with other tools (including upstream BTSes and mailing lists).

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

If you grab a patch from upstream that you know will be in a future
upstream release, the divergence is temporary. You can choose not to
file a bug report in our BTS about it, knowing that it will clear up.
(And if you're somehow wrong, knowing that QA tools will flag that.)
Just as, if you see a bug filed in the upstream BTS, you don't need to
file it in our BTS. In both cases, the package in Debian *has* a bug,
even if it's counterproductive to file it in the BTS.

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

The point of having bug reports is not for change tracking, but for
communication. We've long established that we want maintainers to tell
upstream about what changes they make. Using the BTS just exposes this
communication to the world and allows querying it and noticing when it's
not being done, or when upstream is ignoring it.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Joey Hess
In reply to this post by Pierre Habouzit-3
Pierre Habouzit wrote:
>   Okay, still I dislike the idea a lot.

You actually only read the first sentence at first?

> the BTS is unusable past 100 bugs.

Every package accumulates > 100 closed bugs after some period of time,
and this does not make the BTS unusable for that package, because the
closed bugs are cleverly sorted by the BTS into a "resolved bugs" section.

In my original mail, I said that bugs tagged as divergences could
likewise be sorted out of the way.

> And upstreams wont want to use yetanother bug tracker, they want to use
> theirs

The BTS cleverly allows bugs to be marked as "forwarded" to upstream bug
trackers.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Neil Williams-4
In reply to this post by Pierre Habouzit-3
On Sat, 2008-05-17 at 23:22 +0200, Pierre Habouzit wrote:
>   Okay, still I dislike the idea a lot. the BTS is unusable past 100
> bugs.

? there are ways of managing lots and lots of bugs via custom scripts
and the SOAP interface or usertags or the filters at the end of each bug
index page.

>  For some packages this will add 100 more, that will never go away.

100 patches that upstream never accept? That's revisting the "extensive
patching" thread from earlier. There is no general metric for
determining when a diversion has become a de facto fork but if the
"relationship" with upstream is in such a state that hundreds of patches
for upstream go ignored ad infinitum, it's not a healthy relationship
IMHO.

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

Did you miss the bit about CC'ing the upstream bug tracker or otherwise
wrapping the call such that the upstream bug tracker is notified at the
same time?

The Debian bug is a means of tracking those forwarded bugs and Debian
has been tagging bugs for the purposes of tracking forwarded bugs for a
long time.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Russ Allbery-2
In reply to this post by Joey Hess
Joey Hess <[hidden email]> writes:

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

At first glance, I liked this idea in general, but some of the details
make me wonder if the same concept implemented as a patch tracker separate
from the BTS would work better.  I'm still not sure, though, so some
thinking out loud about the pros and cons.

The points of convergence, where using the BTS as a patch tracker does
save duplication of effort:

* The BTS already has an established state-tracking mechanism and we don't
  have to reproduce that logic.  That potentially (with some development
  work) gives us the ability to keep track of which patches are in which
  versions without redoing that work, which is very nice.  Also you get
  things like tagging for free.

* Existing infrastructure in terms of web site, submission address, and so
  forth so that no one has to set up a new site.

However, against that, I'd want the following features in a patch tracking
system that would need to be developed separately even if we use the BTS:

* Automatic tracking of new patches that show up in Debian packages
  without requiring explicit maintainer action to open and track the patch
  as a bug.  Without this, I'm just not sure this will happen, even if we
  have the best of intentions.  I'm not sure we can raise the level of
  effort across the whole distribution to manually track patch divergences
  without more automated tools.

* Automatic updating of patches on new uploads that have merged them with
  upstream, and automatic dropping of patches that are no longer present.
  We do get some of the latter by using the BTS and Closes:, but the
  automatic updating on merging is as important, I think, and there's
  nothing in the BTS to deal with that.

* As others have pointed out, easy downloading of the last verison of the
  patch.

Also, these aren't bugs in the Debian package, but rather bugs in upstream
(at least arguably), which put them into a different brainspace than
Debian bugs at least for me, and I'd find it awkward and confusing to have
them mixed in with Debian package bugs.  That means that I'd want a
completely separate view for these, which starts looking like a separate
patch tracker.

I think that for this to work, we need to do something as automatic as
possible, and any solution that's based on asking Debian package
maintainers to do additional steps is going to struggle.  Also, just as a
general rule of thumb, one never wants to keep the same information in two
separate places unless they can be automatically synchronized, which to me
argues for making automatic management of the patch tracking system
mandatory.  Anything that's manual runs the risk of quickly drifting out
of date as a maintainer doesn't have time to keep it updated with the
current status of the package, which can end up being confusing enough to
have negative utility.

Of course, having it in the BTS means that anyone can help easily if they
see that things are out of date, and that's a strength.  But if we can
somehow drive the process from uploaded packages rather than from any
manual action, we can enforce up-to-date status of the patch tracker.

Your proposal certainly means less up-front development work, but more
ongoing developer work, with the hope that would be reduced over time with
better tools.  I think, but I'm not at all sure, that we would do better
with something that starts entirely automatic and guaranteed to be
comprehensive, but possibly not with the best quality output (such as
without nicely split-out patches), and with the possibility for the
maintainer to use or introduce tools to improve the quality of the output.

I do want to highlight this paragraph:

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

because I think that's a great summary of the advantages of having a patch
tracking system, whether implemented in the BTS or not.  Most of my
trepidation is about an implementation detail of whether to use the BTS
itself or something similar but much simpler that shares certain
properties.  I think the basic idea of having a site where all the current
upstream divergences of any Debian package are clearly documented and
tracked independent of having to grab Debian source packages is *great*.

The mental model I had was something more like the patch patch that I put
together for gtimer upstream once upon a time [1], except more
automatically driven.  For example, I'm putting more and more of my
packages in Git repositories, and I follow a very standard naming
convention for branches.  I'd love a patch tracking system that could
periodically look at my Git repository (or at the Git repository in an
uploaded v3 git package) and extract the upstream differences from bug/*
and feature/* branches and the reasons for those divergences from the
commit headers (or some other metadata tracking; I'm still not entirely
happy with using git commit --amend to change the documentation of a patch
when I'm not changing the patch).

[1] http://www.eyrie.org/~eagle/software/patches/

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

madcoder (Bugzilla)
In reply to this post by Joey Hess
On Sat, May 17, 2008 at 09:42:47PM +0000, Joey Hess wrote:
> Pierre Habouzit wrote:
> >   Okay, still I dislike the idea a lot.
>
> You actually only read the first sentence at first?

  The 3 first. I assumed that everyone knows it's best to present a
summary of your idea in the first paragraph.

> > the BTS is unusable past 100 bugs.
>
> Every package accumulates > 100 closed bugs after some period of time,
> and this does not make the BTS unusable for that package, because the
> closed bugs are cleverly sorted by the BTS into a "resolved bugs" section.
>
> In my original mail, I said that bugs tagged as divergences could
> likewise be sorted out of the way.

  I'm not convinced, and for what it's worth, it's yet another
(unreadable) place upstreams will have to look at (and won't because
they just can't follow every bug tracker out there that isn't theirs).


--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

madcoder (Bugzilla)
In reply to this post by Joey Hess
On Sat, May 17, 2008 at 09:38:06PM +0000, Joey Hess wrote:
> Loïc Minier wrote:

> allows solving a large percentage of the requirements, and already
> interoperates with other tools (including upstream BTSes and mailing lists).

  If by "interoperates with upstream BTSes" you mean bts-link, then
it's not interoperation because it's one way, and that there's a world
of difference between tracking a few magic fields (bug status and
resolution for closed states) in a html (or when I'm lucky) xml stuff,
and tracking actual content (like patches, modifications of them, and if
they got merged fully, partially, modified, rejected …) both ways.


--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Mike Hommey
In reply to this post by Russ Allbery-2
On Sat, May 17, 2008 at 02:50:33PM -0700, Russ Allbery wrote:
> Also, these aren't bugs in the Debian package, but rather bugs in upstream
> (at least arguably), which put them into a different brainspace than
> Debian bugs at least for me, and I'd find it awkward and confusing to have
> them mixed in with Debian package bugs.

We already have upstream bugs in the BTS, and there is even a tag to
mark them as such.

Mike


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

madcoder (Bugzilla)
In reply to this post by madcoder (Bugzilla)
On Sat, May 17, 2008 at 09:54:54PM +0000, Pierre Habouzit wrote:
> and tracking actual content (like patches, modifications of them, and if
> they got merged fully, partially, modified, rejected …) both ways.

  And to be frank, when rereading that sentence, I know a project that
does that, and it's not a bug tracker at all.

  Second, when I first created bts-link, it was to work both ways, and
give tools to maintainer to submit back. I'm now convinced it's a wet
dream.

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Joey Hess
In reply to this post by madcoder (Bugzilla)
Pierre Habouzit wrote:
>   The 3 first. I assumed that everyone knows it's best to present a
> summary of your idea in the first paragraph.

You seem to have actually missed the second sentence, "A change might be
a bug in upstream, or in the debianisation, or in Debian for requiring
the change.".

nyway, I assume that people read the entirety of what I write before
blindly reacting to it. People who show they're not tend to get ignored
or have their reactions discounted after a while.

> > In my original mail, I said that bugs tagged as divergences could
> > likewise be sorted out of the way.
>
>   I'm not convinced

You're not convinced that divergences could be sorted out of the way in
the bug display? Is there something in the BTS code that makes you think
that cannot be done?

> and for what it's worth, it's yet another
> (unreadable) place upstreams will have to look at (and won't because
> they just can't follow every bug tracker out there that isn't theirs).

You still seem to be missing things that I wrote in my first mail. In
particular, bugs can be forwarded upstream.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: divergence from upstream as a bug

Russ Allbery-2
In reply to this post by Mike Hommey
Mike Hommey <[hidden email]> writes:
> On Sat, May 17, 2008 at 02:50:33PM -0700, Russ Allbery wrote:

>> Also, these aren't bugs in the Debian package, but rather bugs in
>> upstream (at least arguably), which put them into a different
>> brainspace than Debian bugs at least for me, and I'd find it awkward
>> and confusing to have them mixed in with Debian package bugs.

> We already have upstream bugs in the BTS, and there is even a tag to
> mark them as such.

Those are *also* bugs in the Debian package.  Those are, in other words,
bugs that I might go fix if I have the time (or backport a fix for, or
package a new version of upstream for, in the case of fixed-upstream
bugs).  Whereas these are bugs that I've *already* fixed, but which
haven't yet been merged, which to me are rather different.

I do agree that the BTS is capable of tracking such things (archived and
closed bugs, for example) and keeping them out of the same view, but I
guess I wonder whether the BTS is really the right tool to use to create a
separate view for patches.  The version tracking is similar, although the
bug ends up in yet another state when upstream has merged but a new
package hasn't been unloaded yet.  The process by which the patches are
updated for new versions of the Debian package is, however, very
different, in that normally bugs aren't updated at all -- they're either
fixed or still present.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

1234 ... 10