I had originally posted this to debian-private, but in the interest of getting more feedback (and timely feedback, since if this is going into frozen it needs to go *soon*) I'm re-posting it here. (It probably belongs here anyway, as it's not really a closed maintainers-only issue, but more of a "how debian works" issue).
What exactly determines if a new version of a package should go into frozen or unstable? All I've heard is "bug fixes in frozen; everything else in unstable". Actually, though I guess I'd appreciate answers to the general question, what I'd really like is an answer for my specific case: I'm a new Debian maintainer and have just taken over fvwm95. I have packaged up a new version but have not uploaded it because I can't decide if it's frozen or unstable: The main change in this package was that a long-standing "feature" of the upstream source has been fixed (I actually had done this about a week before bug 20866 came in, but it's essentially the same code change) so that Read statements can be used sanely in the configuration files. As a natural improvement, the configuration has now been made to resemble that of fvwm2 extremely closely. (with .hook files all over the place) Points for putting it into unstable: * this package does the configuration of fvwm95 completely differently from before; this may be considered a new feature. * this is by a new maintainer who re-wrote all the control scripts (from skeletons, but still) himself Points for putting it in frozen: * this package closes several (well, three) bugs related to workarounds for the Read problem. * the old style of configuring fvwm95 was so kludgy and allowed for so little user customization that it could have been considered a reasonably important bug. (The fvwm95 configuration was the single thing I thought RedHat 5 did hands-down better than Debian 1.3.1) * the name of the config. files changed between fvwm95 2.0.42a (the version in bo) and fvwm95 2.0.43b (the current version). The package currently in frozen (2.0.43b-2) makes no allowances for this change of names; my new (2.0.43b-3) does - however, if people upgrade first to (2.0.43b-2) and then to (2.0.43b-3) configuration files that weren't modified won't automatically get switched to the new names. That is, upgrading to my new version after upgrading from bo to 2.0.43b-2 leaves certain old config. files (named /etc/X11/fvwm95/*fvwm2rc95) on one's system, even if one hasn't changed a thing. On the other hand, if the system config. files were never touched, upgrading directly from bo to my version clears out the old files. This makes my version preferable over the version currently in frozen for people upgrading directly from bo. * This isn't new upstream source. (than the version currently in frozen) I'd like to see this in frozen, just because it irks me to have RedHat be vastly superior to official Debian on any point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
