[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: divergence from upstream as a bug

Pierre, please fix your MUA to honour the request I made earlier: stop
sending individual copies of messages that you also send to the Debian
lists. It's a request in the mailing list guidelines, and I've
explicitly pointed it out earlier.

Pierre Habouzit <madcoder@debian.org> writes:

> On Sun, May 18, 2008 at 09:57:02AM +0000, Ben Finney wrote:
> > Pierre Habouzit <madcoder@debian.org> writes:
> > 
> > >   That's why the proposal is bad. It doesn't improve that, and
> > > it requires more work from the maintainer. Lose/lose situation.
> > 
> > As I understand it, the proposal is to put *new* information (that
> > Debian source diverges, and exactly why) into an existing location
> > that is already a place we expect upstream to know about (the
> > Debian BTS) and that all Debian package maintainers are already
> > expected to know how to use.
>   But it's NOT ABOUT Debian package maintainers.

You seem to contradict yourself; in the earlier message I quoted
above, *you* raised the issue of "requires more work from the
maintainer". I was responding directly to that point. If you don't
think the effect on maintainers is relevant, I don't see why you
raised it in the first place.

>   More administrivia is never an improvement. See (yeah I know it's
> always about the glibc, but well … that's a very good example for the
> discussion) in the glibc we have
> debian/patches/$arch/$state-$subject.patches. For $state in
> {submitted,local,cvs}. submitted means its sent upstream, local means
> that it's not, cvs that it's a cherry-pick from upstream. Why on earth
> would we need to write that in _yet another place_ ?

Again, the BTS is not "yet another place"; it's already a place where
Debian-specific information needs to be about other changes to the
package. It's a proposal to *consolidate* information into a place
that already has much similar information for similar purposes,
instead of having that information scattered in many places.

>   What Joey's proposal is:
>   * put more burden on the maintainers that already report patch
>     upstream ;

Are these maintainers not recording the fact of a bug in the BTS?

>   * has very few advantages for people that already did that work in
>     their source package in a decent enough way (like the glibc does):
>     the sole advantage I see is that it's predictable where to find the
>     information. But when you want to check a package you have to
>     `apt-get source` it anyways, and if debian/patches is sorted
>     properly, then you'll see that in an obvious way before even
>     launching your browser to look at the BTS.

This assumes that 'debian/patches' is a known standard interface for
all Debian packages, which I would think it clearly isn't in light of
previous threads here. The Debian BTS, on the other hand, *is* a known
standard interface for all Debian packages.

 \      "I busted a mirror and got seven years bad luck, but my lawyer |
  `\                     thinks he can get me five."  -- Steven Wright |
_o__)                                                                  |
Ben Finney

Reply to: