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: <[🔎] 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 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. 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. 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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part