[Zope3-dev] Zope X3.1? Ane rough feeling for release date?

[Martijn Faassen]

Stephan Richter wrote:
> On Monday 10 January 2005 13:25, Martijn Faassen wrote:
> 
>>>> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/RoadMap
>>>> 
>>>> 
>>>> Well, December 2004 has come and passed. ;) Any ideas on how
>>>> far away X3.1 could be?

[snip]

>> I don't think we can say the *only* reason for this 3 month delay
>> is lack of community contributions. Release planning has an effect
>> on it. If you know you're going to release soon, you avoid landing
>> huge changes just ahead of it, for instance.
> 
> Well, when I said December 2004 for a *alpha*, I also placed a bunch
> of conditions on it. One of them was that I have to be satisfied with
> the amount of new features and restructurings to warrant a release.
> The reason we cannot just make releases as we want to is that we do
> not have the man-power to support them.

Wait, wait. The text says:

"Depending on community distributions, we are thinking about releasing
X3.1 in December, 2004. This release will include several cleanups to
the framework and feature the new Pluggable Authentication Service (PAS)
and Workflow packages."

This does not talk about alphas, and the one condition I can see is
'community contributions'. Something went wrong in the communication. 
How can we avoid this in the future?

And please think about some other reasons not to do releases than lack
of manpower; I know this is a factor and I also know it's not the only
factor in this. Let's discuss the other factors.

[snip completely valid lack of contributions arguments]

> And as a sole free contributor I simply pick the tasks I like best as
> well. So often Wiki updates stay behind. Even worse, I have my second
> qualifiers coming up and my wife pushes me to do contract work, so
> that even prolongs the process of getting work done.

Understood. You're not being singled out personally. I'm just worried
about the process that led this happen, and while lack of manpower was a 
major factor, it isn't necessarily the only thing. Were major changes 
introduced late just before the release was planned, for instance? This 
is a surefire way to delay a release.

>> What went wrong with the planning?
> 
> Currently the community is far too small and fluctuating to make any
> reliable prediction.

Releases are not just a matter of prediction, they're also a matter of
planning.

> The to do list for 3.1 is set for a while now, so that's definitely
> not the problem. I can do as much planning as I want to, when people
> do not contribute to the things that have to be done.

One aspect of planning is to cut features if you realize they cannot be
accomplished with the available resources.

Often it's more valuable to have a release in hand with *some* new 
features than to have to wait an indefinite amount of time for all of 
them. While I've seen some people get around this by relying on 
unreleased software, companies like Infrae almost never rely on 
unreleased software as this makes deployment and debugging a lot harder.

This kind of thing can be negotiated. You can present options: "either 
we do all this and wait a few more months for a release, or we add more 
resources and have it out sooner, or we cut these features and have a 
release now". So, do all these features *have* to be in 3.1?

>> How can we prevent this kind of release slippage from happening
>> again in the future?
> 
> Well, I think there are several options.
> 
> 1. It would be really good, if someone could pay me at least for some
> of the time. ;-) Then my contributions would be more steady and I
> could keep track of necessary changes. I think, if some companies get
> together, this should be possible. It could ensure that (a) I keep
> the Wiki updated and everyone posted on changes and (b) I have the
> time to actually do releases and support them.

It would be good to have more resources, agreed. You're an excellent 
resource. As to me, I'm trying hard to get any Zope 3 activity to fit 
into my projects, but it's not easy. I think more frequent releases will 
be one factor that will help bring more activity into Zope 3 
development. We saw a spurt of activity after the X3.0 release, and it's 
slowly dying down now.

> 2. Companies interested in releases need to step up to make them
> happen. As Jim said before, we are willing to make a release for a
> company with a big deadline. The first such deadline will be the
> first pure Zope 3 project that will need a release in May, which
> seems to become the 3.1 target.

I can't help but point out that's a 5 month slippage now compared to the 
original december date. Yesterday it was still 3 months. :)

I think it's important to let time weigh a bit more here compared to 
need. Need-driven releases are one way to do it. There are advantages to 
doing that way. One factor to make this strategy work however is actual 
need. This need seems to be mostly absent, at least in this stage of Zope 3.

The other strategy is time-driven. This helps also with need, as people 
have some idea that a release with their needed features in it will be 
released at a defined date.

> 3. Companies, especially the ones relying on Z3 technologies already,
> need to set aside a little bit of time for one or two programmers to
> contribute. This way we will have a steady stream of contributions
> and planning will become much more predicatable and effective.

Yes, more resources are needed. This is however, not the only factor 
that affects release planning.

I'd like to point out that quite a few companies have invested, for 
companies their size, a *lot* of time and money already in attending and 
organizing Zope 3 sprints. For small companies typical in the Zope 
community, this is a very significant amount of investment. More 
investment from them in the form of regular time from developers would 
be an enormous investment for them they cannot motivate very easily.

In addition, not many companies are in fact using Zope 3 technologies 
already. I'll let you know that even Infrae has barely even started 
using it, and my company is the one that initiated the Five project, so 
this is not for lack of trying!

One way to make more companies invest in Zope 3 is to have a more 
regular release cycle. This will spur open source activity and 
attention, which is what is needed for Zope 3 more than anything right 
now. In addition, companies will know what to expect when, and know 
their contributions will actually be usable within a certain time frame. 
     This will make them more likely to invest. More regular releases 
can be done by getting less ambitious about what gets to be in each release.

>> I know part of the answer is "we need more community
>> contributions", but those will also come more often if people know
>> their contributions will be included in a release in the forseeable
>> future so they can plan deployment. That this is happening is clear
>> from Lennart's question. So please come up with additional answers
>> :)
> 
> I tried to. :-) I know they are not much better, but I cannot help
> it.

Here are some suggestions:

* Stephan Richter is the only force making a release happen at all. 
Thank you, Stephan. I'm just trying to give some feedback about the 
process here, sorry that you're carrying the brunt of it, Stephan.

* Supporting people like Lennart is a very good investment for the Zope 
3 project. People like Lennart will contribute back.

* Letting time weigh a bit more than features or need would help 
shifting the balance towards more frequent releases. This can be 
affected somewhat by flexible planning.

* Having a slightly more predictable release cycle would help people who 
are trying to commit to Zope 3.

* Having a more frequent release cycle would help to draw attention 
towards Zope 3. Attention is a valuable asset in the open source world.

>> I'll again mention time based releases and their merits. Could we
>> go at least a bit more time-based with Zope 3?
> 
> I totally agree. I hope you understand my situation as well.

It's understood, and thank you.

Regards,

Martijn