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
