[Pkg-zope-developers] Re: Bug#335488: Removal request for old zope packages

[A Mennucc]

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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-zope-developers/attachments/20051121/0ecff678/attachment-0001.pgp