On Sun, May 18, 2008 at 06:01:19AM +0000, Ben Finney wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > > I strongly believe that [...] there is no any urgent need for more > > infrastrucre enhancements and yet another places to look at (like > > teaching BTS/PTS of doing additional DD-upstream communication > > processing which brings even more complexity to the scene). > > How is the Debian BTS "another place to look at"? It's already an > essential place to look for information about what changes are made in > a Debian package. > > > In the world of diversion, there should be a single point of > > unification one can safely return to. > > The Debian BTS is already on the list of places to go for information > about Debian package changes. The proposal in this thread doesn't > increase that.
For _debian_ packagers yes. But such a tool would be useful for
upstreams, and form them it *is* one another place to look at. And most
wont, because for large upstreams, there's this huge userbase you see,
and the huge number of downstreams, and huge number of downstreams issue
trackers. They can't look at them all.
If we want to work this idea, we have two ways: either starting a
centralized _common to everyone_ place where all downstreams share their
experience, patches, and so on, and everyone can track wrt _his own_
packaging versions that has or doesn't have the patch (upstream would
just be another layer of that sort FWIW), or we go the decentralized
way.
The former is what launchpad somehow trie{s,d} to do, without the
multiple versionning layers afaict (but I may be wrong, I never really
used it, and that's not the point). Given how mitigated the results of
it are, I'm unsure if it's the way to go (and I don't think the "oh
launchpad is closed source, it's bad mojo" argument is the real reason
why we don't see everyone using launchpad 3 or 4 years after it was
started).
The other way is to provide some glue between all the issue trackers
out there, so that every issue tracker is a source in a giant
bug/patch/content tracking middleware. There are people working on that
afaict (or at least trying to design such tools). This is way better,
and allow upstreams to keep their beloved tool, while we can see
everyone collaborate on bugs, and fetch patches, updates, whatever from
multiple sources (a bit like distributed VCSs work: you have multiple
bug sources you pull from, to create a comprehensive tool in the end).
But the BTS is nowhere near that.
FWIW I've been convinced from a long time that the latter is the way
to go. I've discussed with people trying to design such distributed
BTSes in the past a lot, and bts-link was at the beginning aimed as a
step in that direction too (even if it's not, as I wanted it to be an
_actual_ tool and not vapourware).
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgp3CRHGZqoKo.pgp
Description: PGP signature
