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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
