Roger Ineichen wrote:
On 02.10.2007, at 14:25, Jim Fulton wrote:

On Oct 2, 2007, at 5:25 AM, Martijn Faassen wrote:

Hi there,

Besides causing us a lot of problems here at the Grok
sprint, I also
wonder why in the world are we doing major packaging
and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release!

Sorry, I can't resist to answer the question with some black humor:

I don't know, probably ask the release manager.
Ah, right, we do not have a releas manager anymore since all developer have to release their eggs by itself.

Sorry, but blaming this on the eggification is just a cheap shot. We *do* have a release manager for 3.4. His name is Christian Theune. He wrote a wiki page [1] that specifically spells out instructions for release 3.4.x. eggs. And the 3.4.x eggs are in *stabilization*, as the wiki page accurately says. Stabilization does *NOT* imply moving stuff around like you did. This is 3.5.x business.

Again, don't take it personal! I'm not pointing with my finger to anybody. I just point my finger on the
situation we have right now.

I'm much in favour of the work you're doing (separating pure Python components from their browser views). But with all due respect, Roger, all you've been doing right now is pointing your finger at this situation. I think a more constructive point of view would be looking at how we can *improve* this situation. Let's hear it: what's *your* suggestion?

But what does slowdown mean? Do we need to slowdown the development or do we have to slowdown releasing eggs?

I *think* that Jim means slow down refactoring things and moving things around. Releasing already *stable* stuff is perfectly ok.

Or do we need to slow down till we have a better development process or tools? If so, can we make progress on that?

We should definitely discuss the development process. I've tried to write down some rules [2]. Let's discuss those. Let's improve them. Let's stick to them in the future.

The last two weeks have given us perfect examples of what NOT to do. I think we can all agree on that. Most of could've been avoided if the process had been followed. At this point, I don't really care much about what the process is, as long as it's clear, reliable and easy to follow.


-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to