Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On 18/05/08 at 16:27 +0200, Bas Wijnen wrote: On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote: But the problem we want to solve is making things easier for upstreams. Oh? When I read the proposal, I understood that the problem we want to solve is about tracking changes we make to upstream. Ah, interesting. We are not trying to solve the same problem, which might explain why it's so hard to converge to a single solution. The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. I thought that the problem of tracking changes for Debian developers was already solved by using a VCS and advertising it thought Vcs-*? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, May 18, 2008 at 03:05:41PM +, Lucas Nussbaum wrote: On 18/05/08 at 16:27 +0200, Bas Wijnen wrote: On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote: But the problem we want to solve is making things easier for upstreams. Oh? When I read the proposal, I understood that the problem we want to solve is about tracking changes we make to upstream. Ah, interesting. We are not trying to solve the same problem, which might explain why it's so hard to converge to a single solution. The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. I thought that the problem of tracking changes for Debian developers was already solved by using a VCS and advertising it thought Vcs-*? Seconded, on both account. And if the exact details of how the VCS handles those changes so that an outsider from the maintenance team can contribute aren't obvious, I read about a README.source proposal that seems to fill the gap nicely enough. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWVxWM5PKxQ.pgp Description: PGP signature
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, 2008-05-18 at 17:05 +0200, Lucas Nussbaum wrote: On 18/05/08 at 16:27 +0200, Bas Wijnen wrote: On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote: But the problem we want to solve is making things easier for upstreams. Oh? When I read the proposal, I understood that the problem we want to solve is about tracking changes we make to upstream. Ah, interesting. We are not trying to solve the same problem, which might explain why it's so hard to converge to a single solution. The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. In that case, the fault lies in Debian for not using Forwarded properly. IMHO we should be going out of our way to communicate with upstream using the systems preferred BY upstream, not trying to devise a new one. I know it's a PITA using bugzilla and a gazillion different logins but that is part of the workload. I thought that the problem of tracking changes for Debian developers was already solved by using a VCS and advertising it thought Vcs-*? No, it isn't because Debian developers still need to track where Debian patches have diverged from upstream due to delays in upstream development. Vcs does nothing for that, nothing whatsoever (and I consider it a nonsense to include the entire upstream codebase in our RCS). Going back to the original message: http://lists.debian.org/debian-devel/2008/05/msg00536.html 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. To me, that reads as: Use the upstream trackers to let upstream people know which patches we applied and why. Use the BTS to track the Debian side of the divergence. (Every divergence has two sides, otherwise there would be no difference between Debian and upstream.) I'd like to see that extended to include: 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. Then, when an upstream release finally includes the effect of the patch, remove the patch from Debian and change Fixes: to Closes:. What this proposal is about is identifying where Debian has diverged from upstream so that it is easier for Debian to get back into sync with upstream, not for upstream to get into sync with Debian. (Subtle difference). You appear to want upstream to come to us and for us to provide one-tracker-to-rule-them-all to suit the needs of every upstream team with a Debian package. That isn't going to happen. 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. 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. Upstream have chosen their bug tracker and whether we like it or not, they are unlikely to migrate to one that Debian devises. That way lies Launchpad. Yuck. As an upstream myself, I simply refuse to use that horror. There again, I would also refuse to use the RH or Fedora bug trackers or the OSX bug trackers or Fink or BSD or who knows what else. As upstream, I've settled on the bug tracker I want to use upstream (and in some cases it is the BTS) and I'm not going to go trawling round the distros myself. I want the distros to come to me - as the BTS currently does via Forwarded and the Fedora people do via their methods. I've clearly documented the preferred bug tracker for each project on the relevant website for that project. The BTS cannot be all things to all people and I fail to see that Vcs solves anything with regard to divergence (it only provides history, not divergence). With or without a README.source, Vcs does nothing to help me track which patches that I have applied in Debian are actually diverging from upstream and which have been applied. To find that out, I need to build the
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
2008/5/18 Lucas Nussbaum [EMAIL PROTECTED]: The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. I agree there too. That's the problem I'm interested in solving too, and I think that the proposed solution of having some pseudoheaders added to the patches and an automated system to fetch those patches and publish them automatically would be the best solution. This would allow an easy inspection, not only from upstream, but also from people from other distros, third parties and Debian collaborators. Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On 18/05/08 at 16:44 +0100, Neil Williams wrote: On Sun, 2008-05-18 at 17:05 +0200, Lucas Nussbaum wrote: On 18/05/08 at 16:27 +0200, Bas Wijnen wrote: On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote: But the problem we want to solve is making things easier for upstreams. Oh? When I read the proposal, I understood that the problem we want to solve is about tracking changes we make to upstream. Ah, interesting. We are not trying to solve the same problem, which might explain why it's so hard to converge to a single solution. The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. In that case, the fault lies in Debian for not using Forwarded properly. IMHO we should be going out of our way to communicate with upstream using the systems preferred BY upstream, not trying to devise a new one. I know it's a PITA using bugzilla and a gazillion different logins but that is part of the workload. I think that upstreams would like two different things: - that distros forward patches to their BTS - that distros provide an automated, simple way to see what they patched That sounds logical to have both: - they know that distro devs are not perfect and sometimes don't forward simple patches - they want to know which patches are actually used (and widely tested), because that make them better candidates for integration upstream But maybe I'm just misunderstanding upstreams' needs? I thought that the problem of tracking changes for Debian developers was already solved by using a VCS and advertising it thought Vcs-*? No, it isn't because Debian developers still need to track where Debian patches have diverged from upstream due to delays in upstream development. Vcs does nothing for that, nothing whatsoever (and I consider it a nonsense to include the entire upstream codebase in our RCS). If we have a Formarded-upstream: field in patches.d.o (pointing to the upstream bug for a patch), it would be easy to modify bts-link and automatically monitor those upstream bugs. Going back to the original message: http://lists.debian.org/debian-devel/2008/05/msg00536.html 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. Yes. One problem with this discussion is that we are discussing: What can/can't we do by using, abusing and modifying our current infrastructure (i.e the BTS)? Instead of discussing: What is the real problem that we are trying to solve? What needs to be done to fix that problem? (what features/requirements are needed in a candidate solution?) The discussion is polluted by technical details about BTS things, and this hides the real issues. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote: The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. In that case, the fault lies in Debian for not using Forwarded properly. IMHO we should be going out of our way to communicate with upstream using the systems preferred BY upstream, not trying to devise a new one. I know it's a PITA using bugzilla and a gazillion different logins but that is part of the workload. I think that upstreams would like two different things: - that distros forward patches to their BTS - that distros provide an automated, simple way to see what they patched ok - so two problems, not one. That sounds logical to have both: - they know that distro devs are not perfect and sometimes don't forward simple patches - they want to know which patches are actually used (and widely tested), because that make them better candidates for integration upstream But maybe I'm just misunderstanding upstreams' needs? There's no accounting for the variety in upstream teams - I don't know many that want the second option but I can see that some will probably want it that way, if only because of an MIA DD. I thought that the problem of tracking changes for Debian developers was already solved by using a VCS and advertising it thought Vcs-*? No, it isn't because Debian developers still need to track where Debian patches have diverged from upstream due to delays in upstream development. Vcs does nothing for that, nothing whatsoever (and I consider it a nonsense to include the entire upstream codebase in our RCS). If we have a Formarded-upstream: field in patches.d.o (pointing to the upstream bug for a patch), it would be easy to modify bts-link and automatically monitor those upstream bugs. 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. Yes. One problem with this discussion is that we are discussing: What can/can't we do by using, abusing and modifying our current infrastructure (i.e the BTS)? Instead of discussing: What is the real problem that we are trying to solve? What needs to be done to fix that problem? (what features/requirements are needed in a candidate solution?) The discussion is polluted by technical details about BTS things, and this hides the real issues. 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. Problem 2: Q: How to help upstream find out from Debian which patches are actually in use. A: provide browsable patch files organised by source package (the upstream source package name if it differs) - this sounds like the patches.d.o idea. I'll stick to Problem 1. :-) I think you're right that there are two distinct problems - although I'm still not convinced that Problem 2 is sufficiently common to require a whole new bug/patch tracker. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
(please don't remove Ccs. I added one for a reason) On 18/05/08 at 18:02 +0100, Neil Williams wrote: On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote: The problem I am interested in solving is: It is currently difficult for people not involved in Debian development (upstream, other distros, users) to know which patches we applied, the reason for the patch, and whether they should be interested in that patch or not. In that case, the fault lies in Debian for not using Forwarded properly. IMHO we should be going out of our way to communicate with upstream using the systems preferred BY upstream, not trying to devise a new one. I know it's a PITA using bugzilla and a gazillion different logins but that is part of the workload. I think that upstreams would like two different things: - that distros forward patches to their BTS - that distros provide an automated, simple way to see what they patched ok - so two problems, not one. Yes. That sounds logical to have both: - they know that distro devs are not perfect and sometimes don't forward simple patches - they want to know which patches are actually used (and widely tested), because that make them better candidates for integration upstream But maybe I'm just misunderstanding upstreams' needs? There's no accounting for the variety in upstream teams - I don't know many that want the second option but I can see that some will probably want it that way, if only because of an MIA DD. Well, Vincent Untz (GNOME release manager) explicitely said that he needed that in [1] and [2]. But it's true that more input from other upstreams would be interesting. [1] http://lists.debian.org/debian-devel/2008/05/msg00496.html [2] http://lists.debian.org/debian-devel/2008/05/msg00509.html But my main motivation for providing something like patches.d.o is that, after the openssl debacle, many people have the impression that we are patching a lot of useless stuff, and that we don't know what we are doing. A good answer to that would be to expose all our patches in something like patches.d.o. (sort of we don't hide our problems applied to packages) Also, it's really cheap to do: it can be fully automated. I thought that the problem of tracking changes for Debian developers was already solved by using a VCS and advertising it thought Vcs-*? No, it isn't because Debian developers still need to track where Debian patches have diverged from upstream due to delays in upstream development. Vcs does nothing for that, nothing whatsoever (and I consider it a nonsense to include the entire upstream codebase in our RCS). If we have a Formarded-upstream: field in patches.d.o (pointing to the upstream bug for a patch), it would be easy to modify bts-link and automatically monitor those upstream bugs. 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. 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. Do we really want to solve that? Have submitters been asking for that? Yes. One problem with this discussion is that we are discussing: What can/can't we do by using, abusing and modifying our current infrastructure (i.e the BTS)? Instead of discussing: What is the real problem that we are trying to solve? What needs to be done to fix that problem? (what features/requirements are needed in a candidate solution?) The discussion is polluted by technical details about BTS things, and this hides the real issues. 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. 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. 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? Problem 2: Q: How to help upstream find out
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, 2008-05-18 at 19:39 +0200, Lucas Nussbaum wrote: (please don't remove Ccs. I added one for a reason) (Not sure you want d-devel and direct since I know you are subscribed, so removed that one. :-)) That sounds logical to have both: - they know that distro devs are not perfect and sometimes don't forward simple patches - they want to know which patches are actually used (and widely tested), because that make them better candidates for integration upstream But maybe I'm just misunderstanding upstreams' needs? There's no accounting for the variety in upstream teams - I don't know many that want the second option but I can see that some will probably want it that way, if only because of an MIA DD. Well, Vincent Untz (GNOME release manager) explicitely said that he needed that in [1] and [2]. But it's true that more input from other upstreams would be interesting. [1] http://lists.debian.org/debian-devel/2008/05/msg00496.html [2] http://lists.debian.org/debian-devel/2008/05/msg00509.html I guess it's because that is an over-arching upstream and has to deal with a variety of GNOME teams and Debian DD's. It's kind-of how I expect to use divergence for GPE packages and possibly Emdebian (treating Debian as our upstream). But my main motivation for providing something like patches.d.o is that, after the openssl debacle, many people have the impression that we are patching a lot of useless stuff, and that we don't know what we are doing. A good answer to that would be to expose all our patches in something like patches.d.o. (sort of we don't hide our problems applied to packages) Also, it's really cheap to do: it can be fully automated. If you're sure that all that online disc space really is cheap, it's fine by me. Maybe working with embedded devices has obscured the real cost of online space but I can't help but complain about every extra Mb. :-) 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, 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.) 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: [EMAIL PROTECTED] 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 my upstream BTS doesn't require login to read the bug, are there other reasons
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
(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: [EMAIL PROTECTED] 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
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, 2008-05-18 at 21:40 +0200, Lucas Nussbaum wrote: (you can skip to the end for a summary of what I think we agree on) 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? I suppose bts-link could be utilised - after all, the bug tagged 'divergence' should also be forwarded so it can be updated from there. However, it might be just as well that it is manual. As I mentioned before, removing a tag can be done by anyone so it's not a big issue. 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. ok. 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. Definitely. 2) Build patches.debian.org, fully automated export of Debian patches. Yes. 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? Yes, it does. It could also be possible to add some automation because as the pseudo-header is in the patch, scripts could check that the list of pseudo-headers with a bugs.d.o URL matches the list of diversion bugs obtained via SOAP. Lintian doesn't currently do SOAP queries of the BTS but a QA script should be relatively easy to create. Maybe bts-link could be drafted in to provide some leverage over pseudo-headers mapping to an upstream bug tracker. Lintian could check that the pseudo-header exists. -- Neil Williams [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
