On 18/05/08 at 15:55 +0200, Goswin von Brederlow wrote: > Lucas Nussbaum <[EMAIL PROTECTED]> 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?
See below ; I agree that filing a bug in the Debian BTS could be a solution when there's no way to report the patch upstream. > Esspecially when you have debian specific patches where things are a > clear divergence there won't be an upstream record. If there's a patch that is not going to be useful outside of Debian, and it's 100% clear, why should I even create a bug on the BTS about it? There's no point in discussing something that doesn't need discussion. > 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? The source package's debian/patches dir, which will still be the canonical place to get the up-to-date patch? > > 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. My point is "let's not make this improvement depend on a whole tree of improvements in other parts of Debian infrastructure, if possible". > > 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. That's not enough. It doesn't extract the relevant patch automatically and update the corresponding bug report, and it doesn't work with version-tracking, which would need to be updated have 3 notions: - notfound (already exist) - fixed using a Debian specific patch - fixed in upstream > > 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? No need to duplicate version tracking. We can just export patches for the versions in stable/testing/unstable. Yes, I would add patches.debian.org to the places where upstream should look for patches. But that would be the only place where upstream should look for patches (unless upstream really wants to follow Debian closely, which is not the general case), and upstream would have the guarantee that all Debian modifications to his package are listed on patches.debian.org. Instead of that, you are saying to upstream: "Well, our patches are available on the BTS, but it's not an automated process, so some patches might be missing. Ah, and there's some noise too, since it's mixed with all the bugs we haven't addressed yet." -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
