[Zope3-dev] Re: Known-good-sets problem

[Jim Fulton]

On Oct 6, 2007, at 5:24 AM, Martijn Faassen wrote:

> Hey,
>
> I'm glad some steps are taken!
>
> What I really don't like about this proposal is that it talks about  
> updating index pages. If I understand this right, an updated index  
> page will force everybody that uses this index page into an update.

Only people who ask for updates.

> I don't think this is acceptable.

I think this depends on the use cases.  I think most people would  
like to get bug fixes.  The intent of such a 3.4 index would be to  
give people the latest 3.4 updates which should give no new  
features.  This is intended to mimick what happens with linux package  
respositories.


> Instead I'd suggest you institute a rule that index pages should  
> never be changed after initial publication, just like eggs  
> shouldn't be changed after publication either. Instead, a new index  
> page should be published for each update. People can then choose to  
> switch whenever they like.

You could manage an index like that.  I don't think that would be  
very useful.  IMO, if you want to really nail version numbers, then  
it would be better to just use meta eggs or buildout version  
specifications.

The goal of the index is to give people a stable source of  
distributions that are known to work together.

> My main suggestion is to not forget that this needs to be clearly  
> documented and the document describing which steps to take should  
> be published.

Absolutely. The index is just a mechanism that will enable processes  
that actually address the problems we're struggling with,

> My main worry is that I don't like maintaining dependency lists on  
> remote servers somewhere. My intuition is that we should maintain  
> these lists close to the actual software. With grok we're managing  
> this list now as a versions.cfg in subversion. Anyway, this is just  
> a worry, and we'll have to see how this pans out.

That's a valid approach, at least for some problems.

If the software is an application, the best approach IMO is for each  
release to specify precisely the versions it's using.  If software is  
a platform, then more flexibility may be needed,  This index idea  
seeks to learn from experience with linux distributions.

> We've gone another direction with the Grok project this week, where  
> we publish a versions.cfg on the web that gets included in a  
> buildout.cfg. This approach was based on suggestions by yourself to  
> me, and had been discussed by Philipp on the mailing list earlier,  
> but apparently the choice was made to go for index pages instead.

Yup.  Of course, it only works with buildout.  At the time, I  
remember getting push back from someone that they wanted a solution  
that didn't require buildout.  A custom index is more open both wrt  
packaging technology and to use by different applications.  I think  
Zope 3 would benefit from a stable repository of eggs that can be  
used even if people aren't using Grok or buildout.

Of course, the index technology isn't worth much without solid  
processes behind it.

> So, it's a bit of a shame this extensive work will now be made  
> mostly redundant by these new efforts.

I don't think so.  Certainly, the detective work you've done figuring  
out what's compatibly should be used by whoever assembles a 3.4 index.

> Anyway, we'll be using this for a while at least and we'll wait and  
> see how this new works pans out.

I think the index complements techniques like meta eggs or  
buildout.cfgs with nailed versions.

Also, keep in mind that this effort results from a desire to help and  
because people care.  Be careful about accusing people of not caring  
and then dismissing their efforts to help.

I really appreciate the efforts of Philipp and Baiju to help us make  
incremental progress on the release process for individual projects.  
I think we need to start working (thinking & talking) about the  
release process for the larger Zope 3 ecosystem.

Jim

--
Jim Fulton
Zope Corporation