(you can skip to the end for a summary of what I think we agree on) On 18/05/08 at 19:49 +0100, Neil Williams wrote: > > > I still like the two-stage closure option because sometimes we just need > > > to upload a fix before an upstream release can be made and the bug > > > submitter should know that the bug has been fixed using a divergence > > > whilst still waiting for upstream. > > > > OK, but is that really a problem? Currently, the submitter will receive > > the close message, can read the changelog, and see if his bug was closed > > in a new upstream release, or by a Debian-specific change. > > My point is that the bug submitter should get notification as soon as > the package is fixed in Debian. It is the maintainer who needs to know > about matters after that. It doesn't matter what the submitter receives > as long as it is sent asap. Just using 'divergence' without closing the > Debian side of the bug would leave the bug open but with different tags. > > Don's idea of simply not archiving such bugs (and therefore using > Closes: at the first opportunity) isn't quite what I was thinking but it > would work. Just might not be as easy to scan for those bugs in the bts > webpages. > > > The only > > thing that he would additionaly get is a notification when the change is > > applied upstream and fixed in Debian by a new upstream version. > > Don echoed that sentiment by offering just to not archive bugs tagged > with 'divergence'. I would agree that the submitter doesn't really need > to know when Fixed: is replaced by Closes: - it is a maintainer issue > but one that does need to be publicly visible. OK, but then you have to remove the divergence tag when the change is integrated upstream -- not just close the bug. This would be still be a manual process, right? > > > OK, so problem 1: > > > Q: How to improve Debian forwarding patches to upstream using upstream > > > bug trackers? > > > A: Leave the burden on the DD to handle multiple logins to multiple bug > > > trackers but make life easier in the BTS so that everyone can read the > > > patch without needing a login. This, IMHO, is met by the Fixed|Closed > > > two stage closure idea. > > > > Can you point to some upstream BTS that require you to login to read > > patches? I was under the impression that most BTS give you read access > > without login. > > The DD doesn't just need to read patches, he needs to login and post new > patches and new comments, but yes, I got that bit confused. What I meant > was upstreams where the "bug tracker" is actually private email or > similar. (Some do only offer the login window and tuck a little > "anonymous" box in the top corner.) When upstream has no good way to track patches, I'm perfectly fine with the Debian maintainer choosing that the right way to track patches submitted upstream is to open bugs in the Debian BTS for each of those patches. That's a sensible thing to do. What I strongly oppose is asking all maintainers to do this, even when upstream has a good way to track patches/bugs. > I should have stuck with the original paragraph: > > > I want Debian to go to upstream (as now) and let DD's suffer the hassle > > of divergent upstream bug trackers so as to not force that workload on > > our users or members of different upstream teams trying to work out why > > their code is suffering from a buggy -dev package. If appropriate, feed > > that info into the BTS. > Message-Id: <[🔎] 1211125447.21823.164.camel@holly.codehelp> > > > I fear that this will turn into DDs thinking that it's enough to file a > > bug in the BTS to consider a bug as "forwarded upstream". While it's > > obviously not the case. > > I'm not sure how that follows but I don't want that either. (I suggested > that Fixed would only work if Forwarded was set.) If you enforce the "file a bug in the Debian BTS for each patch you want to see integrated upstream", it might end up sounding like "filing bugs in the Debian BTS is sufficient". A bit like the "if it's lintian-clean, then it's clean" problem. > > If my upstream BTS doesn't require login to read the bug, are there > > other reasons (beside the "submitter want to be notified when the patch > > is applied upstream" one -- see question above) for duplicating the bug > > discussion into the BTS? > > Similar reason to why you added that CC - because when dealing with a > variety of inputs, it is helpful to get an overview of the changes > across all packages. I'm not sure where you see duplication: > > > Use tags in the BTS and custom webpages to let others know which bugs we > > fixed with these patches. If the upstream tracker isn't public, file the > > patches in the BTS too so that everyone can find it. If the discussion happens publicly both in upstream's BTS and in Debian's BTS, then there's a clear duplication problem (dropped Ccs, lost mails, etc). If the discussion happens via private emails with upstream, Cced with the Debian BTS, then it's fine. > and > > > Users can choose whichever bug tracker they prefer - the Debian BTS or > > the upstream bug tracker for the project concerned. It is up to Debian > > to ensure that proper use of Forwarded ensures that the same information > > is available via (but not necessarily in) both. i.e. whichever entry > > route is chosen, links are available to go to the relevant point where > > the information is publicly available (without logins). Whether that > > particular point is in the upstream bug tracker or the BTS is > > inconsequential. The essential point is that it does exist and it is > > linked from both entry points. Users can choose whichever bug tracker they prefer, but DDs should always report patches that should be reported upstream to the upstream BTS. It would be nonsense if DDs started reporting patches for upstream only to the Debian BTS. > I'm not sure which bug tracker I was thinking of regarding logins but > upstreams that only have private email contact would qualify as not > publicly available. ;-) > > In that case, there would be no duplication. As long as both the BTS and > the upstream tracker contain links to the patch itself (no matter where > that is located), that's fine with me. If the upstream bug tracker is so > broken that it cannot do this, the BTS is the only place to put it. ----------------- OK, I think that we generally agree. Let's summarize again to make sure: 1) Encourage maintainers to use patches in debian/patches. Define some useful pseudo-headers. 2) Build patches.debian.org, fully automated export of Debian patches. 3) For patches that need to be sent upstream, a pseudo header in the patch indicates where the submission of the patch to upstream is discussed. -> If upstream has a BTS, the discussion happens on upstream's BTS, and the pseudo header in the patch points there. -> If upstream doesn't have a BTS, a bug is created/reused on the Debian BTS, and the discussion with upstream is Cced with this bug. The pseudo header in the patch points to that Debian BTS bug. Additionally, this bug is tagged +divergence to indicate what it's about. Also, bugs tagged divergence are not archived. So even after the bug has been closed in Debian, the bug can continue to be used to discuss the patch with upstream. Sounds good? -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature