Re: Removal of transitional dummy packages
On Fri, 22 Jul 2005 12:57:14 +0200 (CEST), Santiago Vila [EMAIL PROTECTED] said: I see your point, but policy has never been a permanent thing. I have no idea where you get this impression. For some time we have had a policy which mandated symlinks in /usr/doc. Later we had exactly the opposite policy, one that does not mandate symlinks in /usr/doc. There was a transition plan in progress, in which had compatibility links in place for an extended period, and which every developer had to follow, or else. Sometimes there is a policy which recommends something which is later changed to a should, then to a must. In this case, however, we are switching from dummy packages for upgrades which skip releases are allowed to somebody is going to file bugs on them without asking the maintainer first and ftp.debian.org will honor the reports. No. The practice has always been to mandate smooth upgrades between revisions, and support for upgrades skipping a release being a desirable feature, but not a hard requirement. What is happening here is saying that woody to etch is not feasible, due to the large delta, so the dummy packages re cruft this time around. This is a far cry from a policy that says that support for upgrades skipping versions should be dropped for the future. I think this is more like things we do to support upgrades from oldstable are considered cruft and it's ok and even desirable to remove them. This is not limited to dummy packages, but it also includes versioned dependencies on essential packages which everybody has now installed, and special hacking in maintainer scripts. If we are going to remove things because they are considered cruft, it would be very good to have a common and consistent definition of cruft. The definition of cruft is packages kept around for an upgrade path that does not ecist; in this case, woody - etch upgrades can't be done. Not that the upgrade was deprecated, by policy or otherwise, but the changes made the upgrade path disappear, unfortunately. So woody _ etch dummy packages are cruft; Sarge - Etch +1 may or may not be. There was a tentative policy regarding upgrades in Bug #34672 (you can skip all the flames and go directly to the last message...), but it diverges significatively from current practice. What I would like to see in policy is our current practice, whatever it is. Yeah, raul kinda proposed that maintianrs must support upgrades from oldstable, but the release team has said that this is not feasible. I think the release team has the final words here. manoj -- It's time to boot, do your boot ROMs know where your disk controllers are? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Tue, Jul 19, 2005 at 12:54:56PM +0200, Santiago Vila wrote: On Tue, 19 Jul 2005, Don Armstrong wrote: On Mon, 18 Jul 2005, Santiago Vila wrote: On Mon, 18 Jul 2005, Steve Langasek wrote: In this context, woody-sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. They're not the biggest source of cruft, but on the other hand they are (IMHO) one of the sources for which the proper course of action is clearest. In such case, could we please codify that in policy? Surely the release manager's decision on the matter when properly publisized is information enough? Do you think having this in policy may be harmful? If so, why? We supported upgrades that skip releases in the past, and now we do not (I suppose the fact that our release cycles are much longer have something to do with this). Isn't this the kind of thing that we usually document in policy? IMHO, not really, no; I think this is more like this is the set of architectures that your package must not regress on than it is like these are the arguments that your maintainer scripts must support. I.e., this is a temporal release team recommendation owing to the size of our deltas between releases right now, not a permanent policy that should be enshrined in the Policy document. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Removal of transitional dummy packages
On Fri, 22 Jul 2005, Steve Langasek wrote: On Mon, 18 Jul 2005, Santiago Vila wrote: Do you think having this in policy may be harmful? If so, why? We supported upgrades that skip releases in the past, and now we do not (I suppose the fact that our release cycles are much longer have something to do with this). Isn't this the kind of thing that we usually document in policy? IMHO, not really, no; I think this is more like this is the set of architectures that your package must not regress on than it is like these are the arguments that your maintainer scripts must support. I.e., this is a temporal release team recommendation owing to the size of our deltas between releases right now, not a permanent policy that should be enshrined in the Policy document. I see your point, but policy has never been a permanent thing. For some time we have had a policy which mandated symlinks in /usr/doc. Later we had exactly the opposite policy, one that does not mandate symlinks in /usr/doc. Sometimes there is a policy which recommends something which is later changed to a should, then to a must. In this case, however, we are switching from dummy packages for upgrades which skip releases are allowed to somebody is going to file bugs on them without asking the maintainer first and ftp.debian.org will honor the reports. I think this is more like things we do to support upgrades from oldstable are considered cruft and it's ok and even desirable to remove them. This is not limited to dummy packages, but it also includes versioned dependencies on essential packages which everybody has now installed, and special hacking in maintainer scripts. If we are going to remove things because they are considered cruft, it would be very good to have a common and consistent definition of cruft. There was a tentative policy regarding upgrades in Bug #34672 (you can skip all the flames and go directly to the last message...), but it diverges significatively from current practice. What I would like to see in policy is our current practice, whatever it is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Sunday 17 July 2005 23.28, Joerg Jaspert wrote: On 10353 March 1977, Santiago Vila wrote: we need to remove from the archive all the Woody-to-Sarge transition dummy packages. No, that's not true, we don't *need* to remove woody-to-sarge dummy packages, as they are also woody-to-etch dummy packages. We do not support that. No. So yes, woody-sarge packages should be removed, there is no reason to keep them. Upgrades from woody go via sarge and then to etch. Support and test woody - etch upgrades? No. Knowingly (and on purpose) break woody - etch upgrades where keeping the support is as cheap as keeping a simple arch:all dummy package? I vote no. (Based on a recollection that potato - sarge transitions worked reasonably, with a little hand holding, quite a long time into sarge's testing cycle.) No, I don't think dummy packages should be kept around forever, traces of potato-etch support, IMHO, is certainly not anything worth to keep. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgpkot62CxlH5.pgp Description: PGP signature
Re: Removal of transitional dummy packages
On Tue, 19 Jul 2005, Don Armstrong wrote: On Mon, 18 Jul 2005, Santiago Vila wrote: On Mon, 18 Jul 2005, Steve Langasek wrote: In this context, woody-sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. They're not the biggest source of cruft, but on the other hand they are (IMHO) one of the sources for which the proper course of action is clearest. In such case, could we please codify that in policy? Surely the release manager's decision on the matter when properly publisized is information enough? Do you think having this in policy may be harmful? If so, why? We supported upgrades that skip releases in the past, and now we do not (I suppose the fact that our release cycles are much longer have something to do with this). Isn't this the kind of thing that we usually document in policy? If I have been rude in a previous message (sorry) is because I've seen a wishlist item becoming a RC bug by way of unknown magic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
In a few weeks, we'll start filing RC bugs against the remaining packages. RC bug? What the heck are you talking about? No RC Bug, normal severity. If its a dummy out of an (now) empty source I also agree with the severity to be normal. Which could, btw, have been said in a more kind manner to Mohamed, instead of the quite rude sentence above from Santiago. After a week of Debconf friendlyness, I see that we might easily fall again in our usual flaming style. Debconfs should be mandatory events..:-) As I use to say : I will no more be able to flame someone I've been naked with in a finnish sauna -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On 7/17/05, Joerg Jaspert [EMAIL PROTECTED] wrote: As we only support upgrades to the next release and not any other its very clear to remove them from the archive. Does 'not supporting' equal 'requiring it to fail'?
Re: Removal of transitional dummy packages
On Mon, Jul 18, 2005 at 10:51:23AM +0200, Olaf van der Spek wrote: On 7/17/05, Joerg Jaspert [EMAIL PROTECTED] wrote: As we only support upgrades to the next release and not any other its very clear to remove them from the archive. Does 'not supporting' equal 'requiring it to fail'? It equals we have no expectation whatsoever that upgrades from woody to etch will work for *anyone*, so users are much better off if we deliver this message to them consistently instead of hinting with a couple of remaining transition packages here and there that it might work. We know from experience with sarge that we're already spread very thin where upgrade support is concerned, so it's important that we neither overpromise nor let ourselves be distracted by things that won't actually be of benefit to users. In this context, woody-sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. They're not the biggest source of cruft, but on the other hand they are (IMHO) one of the sources for which the proper course of action is clearest. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Removal of transitional dummy packages
Santiago Vila [EMAIL PROTECTED] writes:
On Sun, 17 Jul 2005, Joerg Jaspert wrote:
On 10353 March 1977, Santiago Vila wrote:
we need to remove
from the archive all the Woody-to-Sarge transition dummy packages.
No, that's not true, we don't *need* to remove woody-to-sarge dummy
packages, as they are also woody-to-etch dummy packages.
We do not support that.
There is no we here.
Oh, there is! *We* ('Debian') have no policy to force maintainers to
make direct upgrade paths from old releases possible, so some
packages support it, most don't. It's the same with downgrades: Some
people care about them and change their packages to make them, most
don't.
Marc, doubting that there are any problems to update the lg-* packages
From woody
--
BOFH #340:
Well fix that in the next (upgrade, update, patch release, service
pack).
pgpD7PQyKnXnQ.pgp
Description: PGP signature
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005 02:40:32 -0700, Steve Langasek wrote: In this context, woody-sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. I agree and I've been busy getting rid of that cruft. It's a pleasure to see how much the maintainer scripts can be simplified on the basis of the assumption that the previous version is sarge or later. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005, Marc 'HE' Brockschmidt wrote:
Santiago Vila [EMAIL PROTECTED] writes:
On Sun, 17 Jul 2005, Joerg Jaspert wrote:
On 10353 March 1977, Santiago Vila wrote:
we need to remove
from the archive all the Woody-to-Sarge transition dummy packages.
No, that's not true, we don't *need* to remove woody-to-sarge dummy
packages, as they are also woody-to-etch dummy packages.
We do not support that.
There is no we here.
Oh, there is! *We* ('Debian') have no policy to force maintainers to
make direct upgrade paths from old releases possible, [...]
Unfortunately, we don't even have a policy to force maintainers to
make upgrade paths from the previous release possible (see Bug #196390).
If we are going to deliver consistently the message that upgrades that
skip releases are not supported and upgrades from the previous release
are supported, could we please agree that upgrades must be smooth, so
that a missing dummy package which makes a package not to be upgraded
as it is expected to be becomes a serious bug?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005, Steve Langasek wrote: On Mon, Jul 18, 2005 at 10:51:23AM +0200, Olaf van der Spek wrote: On 7/17/05, Joerg Jaspert [EMAIL PROTECTED] wrote: As we only support upgrades to the next release and not any other its very clear to remove them from the archive. Does 'not supporting' equal 'requiring it to fail'? It equals we have no expectation whatsoever that upgrades from woody to etch will work for *anyone*, so users are much better off if we deliver this message to them consistently instead of hinting with a couple of remaining transition packages here and there that it might work. We know from experience with sarge that we're already spread very thin where upgrade support is concerned, so it's important that we neither overpromise nor let ourselves be distracted by things that won't actually be of benefit to users. In this context, woody-sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. They're not the biggest source of cruft, but on the other hand they are (IMHO) one of the sources for which the proper course of action is clearest. In such case, could we please codify that in policy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Mon, 18 Jul 2005, Santiago Vila wrote: On Mon, 18 Jul 2005, Steve Langasek wrote: In this context, woody-sarge transition packages are just one form of useless cruft that we should strive to get rid of before the etch release. They're not the biggest source of cruft, but on the other hand they are (IMHO) one of the sources for which the proper course of action is clearest. In such case, could we please codify that in policy? Surely the release manager's decision on the matter when properly publisized is information enough? Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
* Mohammed Adnène Trojette [Sun, 17 Jul 2005 22:46:19 +0200]: Hello Debian mainainers, Hi! [2] http://adn.diwi.org/wiki/index.php/DummyPackagesList [3] http://adn.diwi.org/wiki/index.php/DummyPackagesStatus This two pages are asking for authentification. I guess this is not intended? Thanks for your initiative, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 In Italy, for 30 years under the Borgias they had warfare, terror, murder, bloodshed, but they produced Michelangelo, Leonardo da Vinci, and the Renaissance. In Switzerland they had brotherly love - they had 500 years of democracy and peace, and what did that produce? The cuckoo clock. -- Harry Lime in “The Third Man” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Sun, Jul 17, 2005, Adeodato Simó wrote: This two pages are asking for authentification. I guess this is not intended? Oops! It should be fixed ;-) Thanks. PS: I read the list. -- adn Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Sun, 17 Jul 2005, Mohammed Adnène Trojette wrote: Hello Debian mainainers, In accordance with the Etch wishlist^wTODOList[1], Do not confuse a personal wishlist with a real todo list. we need to remove from the archive all the Woody-to-Sarge transition dummy packages. No, that's not true, we don't *need* to remove woody-to-sarge dummy packages, as they are also woody-to-etch dummy packages. This is why Clément Stenac and I have tried to establish a list of the packages to be removed[2]. This[3] page also explains how the list was built. If one of your packages is listed here[2], please remove it from your control file and ask ftp-masters for its removal from the archive by filing a bug on ftp.debian.org (of course, we might have made some mistakes computing this list, please contact us on dummy at diwi dot org should you have any question/remark.) In a few weeks, we'll start filing RC bugs against the remaining packages. RC bug? What the heck are you talking about? You can argue that we don't have a clear and defined policy about how long should a dummy package be kept in the archives, but it is definitely *not* in policy that dummy packages *have* to be removed after one release. Please do not make policy by submitting bugs.
Re: Removal of transitional dummy packages
On 10353 March 1977, Santiago Vila wrote: we need to remove from the archive all the Woody-to-Sarge transition dummy packages. No, that's not true, we don't *need* to remove woody-to-sarge dummy packages, as they are also woody-to-etch dummy packages. We do not support that. No. So yes, woody-sarge packages should be removed, there is no reason to keep them. Upgrades from woody go via sarge and then to etch. In a few weeks, we'll start filing RC bugs against the remaining packages. RC bug? What the heck are you talking about? No RC Bug, normal severity. If its a dummy out of an (now) empty source package, then ftp.debian.org Bug with CC to maintainer could be better. You can argue that we don't have a clear and defined policy about how long should a dummy package be kept in the archives, but it is definitely *not* in policy that dummy packages *have* to be removed after one release. As we only support upgrades to the next release and not any other its very clear to remove them from the archive. -- bye Joerg ribnitz Ganneff: NM-queue ist das schnellste zu uploadrechten für ein paket, oder? youam ach aqua^Wribnitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal of transitional dummy packages
On Sun, 17 Jul 2005, Joerg Jaspert wrote: On 10353 March 1977, Santiago Vila wrote: we need to remove from the archive all the Woody-to-Sarge transition dummy packages. No, that's not true, we don't *need* to remove woody-to-sarge dummy packages, as they are also woody-to-etch dummy packages. We do not support that. There is no we here. You don't want to support them for your packages? Fine, they are your packages, but I support them for my packages (see Bug #312336 for example). So there is no we. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
