[Zope3-dev] December release post-mortem

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> ...
> 
>> How do you assemble releases 'from releases'? I'm not sure I 
>> understand that. You mean make a Zope 2 release using a Zope 3 release?
> 
> 
> No, I mean using eggs.  Zope should be broken into separate projects
> with their own eggs.  A Zope release might just be an egg with 
> dependencies.
> Or it might just be a collection of eggs.

Ah, makes sense. A 'meta-package', so to speak. Works well in Debian, so 
I think that's an interesting pattern to follow. As long as we can do 
those micro releases quickly -- the problem is that Zope 3 is one 
project, and we want one communication channel, as we simply don't have 
enough people otherwise. From another perspective it's many projects, 
though.

>> You know my position concerning the repository and the release; I'd 
>> prefer them to be kept as similar as possible to simplify the release 
>> process. I hope we can go in that direction. It also makes things more 
>> predictable to developers. We noticed that some Zope 3 packages 
>> weren't packaged into Zope 2 after the release, even though in a 
>> developer's sandbox of Zope 2 they were there.
> 
> 
> Right. If eggs work out, then a respository check out will be a lot 
> smaller,
> but will download needed eggs.  This would be a replacement of the
> use of externals we have now.

A risk here is that if I find a bug in package X, I can't easily track 
it into package Y and fix it there, as package Y is an egg. The current 
system doesn't have this problem.

>> As a side issue: From the perspective of Five, it is beneficial to 
>> have as much Zope 3 code included into Zope 2 releases, as that gives 
>> us an opportunity to start using this functionality right away, 
>> exposing it to Zope 2, without waiting for a new release.
> 
> Understand though that there is nothing like a backward compatibility
> promise for something that hasn't been released.

Yes, but Zope 2 included *less* than Zope 3 in the most recent release, 
and I'd like *all* packages that are in a Zope 3 release to be available 
in a Zope 2 release. I.e. Five doesn't want packages that aren't in a 
Zope 3 release, but not less either.

[snip]
>>   (If you're interested I can try to explain some of my thinking a bit 
>> deeply.) Eggs are a nice distribution mechanism, but I'd also want the 
>> knitting process to work for a SVN checkout -- developers working with 
>> SVN need to be very easily work with a 'knitted' version, so perhaps 
>> svn:externals will remain a valuable tool.
> 
> Assuming that eggs fullfill their promise, I think I'd
> rather use eggs than externals.

Sure, but see the risk I mentioned earlier in this mail.

>>> As part of this decomposition, we need to make zope.app much smaller.
>>>  Early in Zope 3 development, I proposed a simple rule for
>>> organization of the repository: Anything that depended on zope.app
>>> went in zope.app. Anything else went in zope.  If there was doubt,
>>> put it in zope.app.  I think that served us well at the time, but I
>>> think we've moved beyond that,  I'd like to migrate most of zope.app
>>> elsewhere.  Zope 2.10 should not include zope.app.
>>
>> This worries me; Five is currently using massive quantities of code in 
>> zope.app, and as expressed above, I value Five having access to 
>> potentially all Zope 3 code that's in a Zope 3 release.
> 
> The code that Five is using will still be available, but it will be
> somewhere else (with necessary backward compatibility hacks).

As long as Zope 2.10 contains all packages in Zope 3.

Regards,

Martijn