Bug#340921: RM: automake1.6 -- RoM; Superseded by automake1.{7,8,9}

2005-11-30 Thread Jeroen van Wolffelaar
On Tue, Nov 29, 2005 at 06:05:26PM +0100, Peter Eisentraut wrote:
 I don't think this removal was such a good idea.  Certainly, cleaning up 
 the archive is a valid goal, but breaking dozens of packages along the 
 way is not.  The submitter of this bug did not offer the affected 
 packages any upgrade path.  Some of the affected packages have reached 
 maintenance stages where it's unreasonable for the upstream maintainer 
 to make a new release just to upgrade automake.  Note that 
 re-automaking all the affected packages as part of the packaging is 
 likely to create larger diffs and will thus increase the size of the 
 archives, perhaps more than what is saved by removing automake1.6.

I think it was a good idea to remove it. As the maintainer noted, it's
the 5th or so automake version in the archive, of series of similar (but
indeed not 100% compatible) versions. It's laudeable to try to reduce
the number of versions out there.

The maintainer also announced his intention four months ago, cc'ing all
involved maintainers, and there wasn't a single public reply to his
mail afaics. Also he filed wishlist bugs on all involved packages 5
weeks ago, giving again ample time for people to prepare on migrating.
The removal also doesn't involve any inconvenience for users, it only
prohibits rebuilds and new uploads.

This, together with the fact that upgrading to automake1.7 (available
in Debian well over 3 years now) is said to be really simple and also,
assistance was offered by the automake maintainer, made it an easy call
for me. Sure it'll cause some short-term inconvenience, but (1) it's
early in the release cycle, and (2) we're ending up with less versions
of the same software to maintain in etch etc.
 
 automake1.6 did not have any bugs and did not burden anyone (except the 
 maintainer?), but he did not respond to my offer to orphan the package 
 first.  I suggest that to unbreak the situation automake1.6 be 
 reuploaded and removed after all build dependencies are gone.  Would 
 this be acceptable?

Please don't, and spend your energy on upgrading your package(s) to
automake1.7 or later, something you'll eventually need to do anyway.
If packages were only removed after the last single package stops
needing it, we'd be having tons of different versions of same packages
in the archive. I do pay attention whether there's some sort of
migration plan (advance warning to affected package maintainers being
the simples instance of it), and whether the amount of
reverse-(build-)depends is overseeable, but both were in the green in
this case.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber  MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#340921: RM: automake1.6 -- RoM; Superseded by automake1.{7,8,9}

2005-11-30 Thread Eric Dorland
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) wrote:
 On Tue, Nov 29, 2005 at 06:05:26PM +0100, Peter Eisentraut wrote:
  I don't think this removal was such a good idea.  Certainly, cleaning up 
  the archive is a valid goal, but breaking dozens of packages along the 
  way is not.  The submitter of this bug did not offer the affected 
  packages any upgrade path.  Some of the affected packages have reached 
  maintenance stages where it's unreasonable for the upstream maintainer 
  to make a new release just to upgrade automake.  Note that 
  re-automaking all the affected packages as part of the packaging is 
  likely to create larger diffs and will thus increase the size of the 
  archives, perhaps more than what is saved by removing automake1.6.
 
 I think it was a good idea to remove it. As the maintainer noted, it's
 the 5th or so automake version in the archive, of series of similar (but
 indeed not 100% compatible) versions. It's laudeable to try to reduce
 the number of versions out there.
 
 The maintainer also announced his intention four months ago, cc'ing all
 involved maintainers, and there wasn't a single public reply to his
 mail afaics. Also he filed wishlist bugs on all involved packages 5
 weeks ago, giving again ample time for people to prepare on migrating.
 The removal also doesn't involve any inconvenience for users, it only
 prohibits rebuilds and new uploads.
 
 This, together with the fact that upgrading to automake1.7 (available
 in Debian well over 3 years now) is said to be really simple and also,
 assistance was offered by the automake maintainer, made it an easy call
 for me. Sure it'll cause some short-term inconvenience, but (1) it's
 early in the release cycle, and (2) we're ending up with less versions
 of the same software to maintain in etch etc.

Thanks Jeroen, could not of put it better myself. 

And to address the no upgrade path concern, in the majority of cases
there is no path, the newer versions of automake will just
work. Otherwise some minor changes may need to be made, and I'm here
to help if it's needed. I think about half the bugs I filed were
already closed before the removal without me doing anything, so the
difficulty can't be too great. 

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature


Bug#340921: RM: automake1.6 -- RoM; Superseded by automake1.{7,8,9}

2005-11-29 Thread Peter Eisentraut
I don't think this removal was such a good idea.  Certainly, cleaning up 
the archive is a valid goal, but breaking dozens of packages along the 
way is not.  The submitter of this bug did not offer the affected 
packages any upgrade path.  Some of the affected packages have reached 
maintenance stages where it's unreasonable for the upstream maintainer 
to make a new release just to upgrade automake.  Note that 
re-automaking all the affected packages as part of the packaging is 
likely to create larger diffs and will thus increase the size of the 
archives, perhaps more than what is saved by removing automake1.6.

automake1.6 did not have any bugs and did not burden anyone (except the 
maintainer?), but he did not respond to my offer to orphan the package 
first.  I suggest that to unbreak the situation automake1.6 be 
reuploaded and removed after all build dependencies are gone.  Would 
this be acceptable?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]