#include <hallo.h> * Luigi Gangitano [Wed, Apr 26 2006, 12:21:52PM]: > >>Squid 3 is not release ready. And with current plans should not > >>release > >>with etch. > > > >Upload to experimental, not as new source. > > Why not? Since I'd like to make squid3 easily available to all those > that want to try the new features, without braking the existing squid > package, unstable is the most obvious solution (autobuilt on all > archs, widely deployed on desktop/testing machine, no configuration > needed), don't you think?
How would that interact with running squid installations? Please tell us what the actuall constraints are instead of repeating "needs to stay here, needs to stay there". I assume you want to: - make a package name more clear to show what the purpose of that package is. Eg. "squid-experimental" - clearly state that this is an experimental package, that it does not share configuration or cache data with default squid installation - upload the package either to unstable or to experimental, depending on your opinion of how much damage the package may create. Actually, I would upload it to experimental only. - keep config directories and cache data separate - when squid-3.x is released, upgrade squid package with the new version PLUS the changes from squid-experimental PLUS transition code if needed. THEN upload the package as "squid" to experimental, THEN ask people to install it from experimental to test the upgrade path. And then move it to unstable for more wide testing. > Unstable is where such testing can happen, think zsh-beta or > different versions of postgres. Ehm... zsh-beta is a different class of application, not something that can fsck up your system RSN by offering remote accessible vulnerability. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
