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

Re: divergence from upstream as a bug



Lucas Nussbaum <lucas@lucas-nussbaum.net> writes:

> On 17/05/08 at 17:01 -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..
>
> After re-reading the whole thread, I still have several concerns
> about the idea of tracking each divergence from upstream as a bug in
> the BTS, and I still don't think it's a good idea.
>
> 1) It duplicates information. We will already duplicate information
> between the patch description and the upstream bug tracker or mailing
> list where the patch was forwarded (but the patch description should
> only a summary of the discussion happening upstream). I don't see any
> reason to additionally duplicate information into the BTS, especially
> since the discussion of the patch would have to happen both on the
> upstream bug tracker and the BTS. (=> huge Cc lists, if it's even
> possible!)

Who says upstream has a BTS or that the bug was discussed there?
Esspecially when you have debian specific patches where things are a
clear divergence there won't be an upstream record.

I agree with you that the bug description should be a summary. The BTS
would be the history of the patch. The how and why it became. If that
info is in upstreams BTS then you would just link that.

> 2) It makes the BTS another place to look at for upstreams or other
> distros interested in our patches.

What other place is there currently besides extracting the source and
checking that?

> 3) BTS bugs do a poor job at providing summaries, so nobody can have a
> quick glance at a patch and determine its status. Sure, a design was
> posted for a "summary" feature for the BTS (and I'd like that
> feature). But there's no implementation yet.

Lets not improve things because we haven't improved things yet?
This is a stupid argument.

> 4) The bureaucracy/usefulness ratio looks very high to me. After all,
> we spent 15 years not doing that, and it seems to me that many patches
> are small and don't require any discussion, so the overhead would be
> huge. Maybe we could try a simpler solution first?

"bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
the BTS. Not mutch work.

> A saner solution would be to only use the BTS when it's not possible
> to discuss the patch with upstream. We could do the following:
>
> - add pseudo-headers in the patches for:
>   + URL of the bug that the patch is fixing (could be a Debian
>     bug or an upstream bug, or even another distro's bug)
>   + URL of the discussion (patch, ML thread) happening upstream about
>     this patch
>
> - encourage maintainers to use those pseudo-headers
>
> - publish patches on patches.debian.org so upstreams, other distros
>   and users can have an easy look at them.
>
> - make patches.debian.org able to track upstream bugs and mark
>   patches that were integrated upstream as such.
>
> - when there's really no place to submit patches upstream, encourage
>   maintainers to file a bug in the Debian BTS about the patch, so
>   the discussion about it can happen there. (with all the
>   infrastructure you want in the BTS about it -- see the many mails in
>   the thread about technical details).

So you not only duplicate version tracking in patches.d.o but also add
that and the BTS to the places upstream should look for patches?

That contradicts your 2) above.

> - Lucas

MfG
        Goswin


Reply to: