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
