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


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 Fulton
Zope Corporation

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to