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 package and see the failure messages from patch. Not ideal. This way, I can indicate to the bug submitter that the bug is fixed in Debian (using a divergence) by including (Fixes: #1234) in a new Debian revision. Until the bug is fixed in an upstream release, I still see that the package has bugs that are Fixed but not Closed. bts-link takes care of updating the tags on the Fixed bugs (because they are also forwarded) so that when the upstream release is made, I know which patches are included upstream. I can then remove those patches, build the new upstream release, implement any new divergences if needed and upload with (Closes: #1234). -- 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
