(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 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. :-) heh :-) -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature