Bug#335488: [Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages
On Thu, Nov 24, 2005 at 09:54:11PM +0100, Fabio Tranchitella wrote: On gio, 24 nov 2005, Jeroen van Wolffelaar wrote: I mailed you guys now because I think that by that time, it is no longer possible to consider doing anything for etch, and that changes like discontinuing a branch of software in Debian take time. Anyway, thank you all for considering this, I'll now shut up, and let the people who are doing all the work on zope decide about this. Please, do not shut up.. I'm really interested in your arguments and I suppose others too. As far as I'm concerned, the main zope products already depend on zope2.8 | zope2.7 (and I'm thinking about plone and cps), so removing the latter one shouldn't be too hard. I completely agree that we'll have to remove zope2.7, but I would prefer to leave it around untill the removal is really needed, mainly because there are a lot of people out using zope2.7 within testing (or even unstable) because zope products life-cycle is faster than debian stable's one. Plone will not depend anymore on zope2.7 in a near future (with the next release, the development team will start using Five, which is shipped with zope2.8 only), and I think that could be the right moment to drop zope2.7 support. Other opinions? It all depends on the various timelines. One thing to consider is that newer versions typically don't get as much testing by users as long as people still have a good reason to use the old version, but as you say, there's still an important program (plone) depending on zope2.7. In any case, what you suggest, seems reasonable to me, the quite uninformed outsider. I don't think I've more useful things to say about this :). --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#335488: [Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages
On Mon, Nov 21, 2005 at 09:57:00AM +0100, A Mennucc wrote: Too many zope(s)? That was discussed already. Problem is: there are a lot of differences between zope2.6, zope2.7 and zope2.8 : you cannot simply upgrade and hope your portal will continue to work. Some time ago I had a conversation with people who work in a company building web services: they worked with zope 2.6 (although 2.7 was around) since it was OK for them, and they had no plans in switching (at that time), since it would cost too much time and failures (that their clients were not willing to pay for!). Isn't this *exactly* the usecase for people staying with stable? Debian has its own release cycle, *exactly because* software during its development has incompatible changes. Because of Debian releasing and having branches (stable, testing, unstable), I believe it would be best if there were not too many versions of the same software around, where I'd put 'too many' as more than two for complicated software (or software at the heart of the dependency tree) that went through a major bump, and 'more than one' for every other piece of software. For example, we only ship one version of gnome, one version of kde, one version of perl, and for example: two versions of apache, two versions of mysql, two versions of PHP. Note that zope certainly isn't the only piece of software in Debian of which I think there could be a reduction in the number of simultaneously supported versions, postgresql (4), python (4) and gcc (5) are three high-profile examples of where I similarly think redution should be aimed at before etch nears a releaseable state. I do not think it's a good thing to have multiple minor versions in the archive simultaneously, especially considering zope2 is apparantly obsolete already. We will see what happens by the time etch is released. I mailed you guys now because I think that by that time, it is no longer possible to consider doing anything for etch, and that changes like discontinuing a branch of software in Debian take time. Anyway, thank you all for considering this, I'll now shut up, and let the people who are doing all the work on zope decide about this. Bye, --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#335488: [Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages
On gio, 24 nov 2005, Jeroen van Wolffelaar wrote: I mailed you guys now because I think that by that time, it is no longer possible to consider doing anything for etch, and that changes like discontinuing a branch of software in Debian take time. Anyway, thank you all for considering this, I'll now shut up, and let the people who are doing all the work on zope decide about this. Please, do not shut up.. I'm really interested in your arguments and I suppose others too. As far as I'm concerned, the main zope products already depend on zope2.8 | zope2.7 (and I'm thinking about plone and cps), so removing the latter one shouldn't be too hard. I completely agree that we'll have to remove zope2.7, but I would prefer to leave it around untill the removal is really needed, mainly because there are a lot of people out using zope2.7 within testing (or even unstable) because zope products life-cycle is faster than debian stable's one. Plone will not depend anymore on zope2.7 in a near future (with the next release, the development team will start using Five, which is shipped with zope2.8 only), and I think that could be the right moment to drop zope2.7 support. Other opinions? Thanks for your suggestion, -- Fabio Tranchitella http://www.kobold.it Studio Tranchitella Assoc. Professionale http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Bug#335488: [Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages
On Mon, Nov 21, 2005 at 12:40:23AM +0100, Jeroen van Wolffelaar wrote: On Sun, Nov 20, 2005 at 09:53:37PM +0100, Fabio Tranchitella wrote: On dom, 20 nov 2005, Jeroen van Wolffelaar wrote: Why isn't the canonical zope version simply called 'zope' here? If I'd remove zope, there will be no 'zope' package anymore for people to in.. zope2.7 has Provides: zope Oh, so there are currently no less than *four* versions of zope in unstable? yes (but it will go down to 3 once zope=zope 2.6 is removed) Too many zope(s)? That was discussed already. Problem is: there are a lot of differences between zope2.6, zope2.7 and zope2.8 : you cannot simply upgrade and hope your portal will continue to work. Some time ago I had a conversation with people who work in a company building web services: they worked with zope 2.6 (although 2.7 was around) since it was OK for them, and they had no plans in switching (at that time), since it would cost too much time and failures (that their clients were not willing to pay for!). So, as long as we can manage to keep them secure and working, I approve having multiple zopes around. I'd very strongly suggest to make that zope2 and zope3 only I would not. while there surely can be a lot of difference between minor versions, I do not think it's a good thing to have multiple minor versions in the archive simultaneously, especially considering zope2 is apparantly obsolete already. We will see what happens by the time etch is released. You have to think about people using stable, and people who weight stability more than innovation The main factor that would weight against keeping zope2.7 in etch would be: - will zope.com provide hotfix for zope2.7 if a bug is found? or otherwise - can we backport security fixes to zope2.7 if a problem is found in 2.7? Unfortunately (though I swam in zope some time in the past) I admit I may not be up to the second task In case there's a security issue in etch, then all of them need to be fixed after all, so it saves you as maintainers also some effort. again: as long as we mantainers can stand the burden, I see no problems in keeping multiple versions (*) But max two then? Only some really big packages have more than two versions, and even there it's typically too much (kernel, python, ...). (*) indeed Debian will have less kernels around in the future, and the reason is that security was not powerful enough to keep up with too many of them. but this is not a big problem for zope : zope hotfixes are easy to analyze and deploy: it took me 45 minutes to fix bug 334055 ; (unfortunately the fix is not part of the security archive yet; I have queried the security team but nobody answered me for long time, up to Sun 20th, when joey wrote me that he is taking care of it, so the fix should be published in the archives in short time) BTW it seems that the new versioned BTS is not understanding that 334055 was fixed in sid but not in sarge... I now send a found command, and see if this corrects the BTS! bye a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef signature.asc Description: Digital signature
Bug#335488: [Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages
Jeroen van Wolffelaar writes: On Sun, Nov 20, 2005 at 09:53:37PM +0100, Fabio Tranchitella wrote: On dom, 20 nov 2005, Jeroen van Wolffelaar wrote: Why isn't the canonical zope version simply called 'zope' here? If I'd remove zope, there will be no 'zope' package anymore for people to install. Well, in my opinion having no 'zope' package is a good thing: zope development is focused on two branches (zope2.x and zope3) so at least two packages will have to coexists. When sarge has been released, zope2.7 was the 'default' zope version, and now it could probably removed in favour of zope2.8, but there are *a lot* of differences between them (read: the Five framework). Oh, so there are currently no less than *four* versions of zope in unstable? calm down. I'd very strongly suggest to make that zope2 and zope3 only, while there surely can be a lot of difference between minor versions, I do not think it's a good thing to have multiple minor versions in the archive simultaneously, especially considering zope2 is apparantly obsolete already. that's rubbish, not an argument. plone doesn't work with zope3. In case there's a security issue in etch, then all of them need to be fixed after all, so it saves you as maintainers also some effort. As with the name, ok, I see. Another point is that often there is no upgrade path between zope major releases (between 2.7 and 2.8, for example), and having separated packages could be handy in these situations. So, as zope maintainer and *user* I really would prefer to not have a 'zope' package but rather install a zopeX one, where X is the release I want to use. So, in short, I'd really really prefer to have just one single zope version in Debian, rather than multiple. I think this would be a bad thing for zope users and developers. But max two then? Only some really big packages have more than two versions, and even there it's typically too much (kernel, python, ...). it should be a goal to have one 2.x and one 3.x version in etch. if 2.x can be avoided, that's ok. That are separate things, and I'd like to have those orphaned bugreports reassigned to ftp.debian.org so I can deal with them. I'll reassign them to ftp.debian.org. Thank's a lot! yeah, thanks a lot for your constructive comments! Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335488: [Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages
On Mon, Nov 21, 2005 at 01:16:40AM +0100, Matthias Klose wrote: Jeroen van Wolffelaar writes: On Sun, Nov 20, 2005 at 09:53:37PM +0100, Fabio Tranchitella wrote: On dom, 20 nov 2005, Jeroen van Wolffelaar wrote: Why isn't the canonical zope version simply called 'zope' here? If I'd remove zope, there will be no 'zope' package anymore for people to install. Well, in my opinion having no 'zope' package is a good thing: zope development is focused on two branches (zope2.x and zope3) so at least two packages will have to coexists. When sarge has been released, zope2.7 was the 'default' zope version, and now it could probably removed in favour of zope2.8, but there are *a lot* of differences between them (read: the Five framework). Oh, so there are currently no less than *four* versions of zope in unstable? calm down. Ok :) I'd very strongly suggest to make that zope2 and zope3 only, while there surely can be a lot of difference between minor versions, I do not think it's a good thing to have multiple minor versions in the archive simultaneously, especially considering zope2 is apparantly obsolete already. that's rubbish, not an argument. plone doesn't work with zope3. Hence the 'apparantly', I indeed don't know about pro cons of each version, which was already quite obvious to myself as I didn't know about zope3 at all yet. Nor should I per se know this, as I'm not involved in zope. I'm speaking here as stakeholder for the FTP archive in general, and also partly for the release team's (and security team's) express wish to strongly reduce the number of different-version-same-package occurances in Debian. Note also that above I didn't suggest to drop zope2 altogether, my suggestion to go for one zope version was of before I knew there was a zope3 -- I meant one zope2.x version. it should be a goal to have one 2.x and one 3.x version in etch. if 2.x can be avoided, that's ok. Cool, that's great. Thank's a lot! yeah, thanks a lot for your constructive comments! I don't think I can very constructively contribute in my role as FTP team member to zope packaging, not being involved in zope, I merely wanted to express my concern about the number of zope packages in the archive. How to deal with that, is something only people interested in zope itself can usefully determine. Thanks, --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]
