[Framework-Team] Re: proposed plone 3.1 timeframe

[Martin Aspeli]

Wichert Akkerman wrote:
> I think it is much more important to do a time-based released then a
> feature-based release. If we do the letter we will end up waiting months
> before things are ready and we will end up with a 3.1 in june and 4.0 in
> 2009.

Oh, I agree (at least for 3.x releases - for 4.x I think we may need a 
slightly different balance). I just don't think your proposed times are 
realistic given how I've observed most people work.

Or, let me put it another way: Several developers (myself included) have 
taken aim at getting things into 3.1. It feels a bit unfair to be given 
a very short amount of time from announcement to deadline. It feels 
doubly unfair to be expected to deliver that over what is a family 
holiday for a lot of people.

This is of course not supposed to be a big problem (that's part of the 
point of .x releases), but there's still a psychological draw from 
having a deadline and a release to work towards. Striking a balance is 
important.

> My aim is to use 3.x releases to get new features out to people
> in a predictable and painfree way. If that means 3.1 is tiny and we'll
> do a 3.2 4 months later I see no problem in doing so.

Yes, I completely agree with this sentiment.

>> I also think you need to give people a bit more warning. No-one works 
>> without a deadline. I'm not aware of any serious 3.1 branches at the 
>> moment, apart from a few sprint leftovers. If you spring a deadline on 
>> the community that's only a few weeks away, people won't take it 
>> seriously (or just won't react at all).
> 
> I'm aware of three things that should be ready in time. I'm sure about
> two of them.

Which things?

>> Personally, for 3.1 I'd like to:
>>
>>  - Add GS better handlers for portlets and content rules
>>  - Improve portlets blocking UI
>>  - Ship with collection portlet
>>  - Ship with plain-text/kupu portlet
>>  - See the UberSelectionWidget finished
>>  - Support inline/KSS editing for formlib-based content
>>  - Support inline/KSS validation of formlib forms
>>
>> Now, most of the above are begun, but none is in a mergable state right 
>> now. I'm not going to wreck myself over Christmas to get it done, when 
>> I'll be with my family. I suspect I'm not the only one that has that 
>> attitude.
>>
>> Secondly, if you expect working buildouts, with full migrations for the 
>> review deadline, I think you're asking a lot. There's a lot of "tidy" 
>> work to go into migrations and final polish, especially when it comes to 
>> keeping up with other movements on the 3.0 branch. I won't spend that 
>> time upfront on all the proposals above because (a) I don't have time 
>> and (b) you may say no to my PLIPs, in which case all that work's wasted 
>> (migrations are unlikely to stay current even if they're pushed for 4.0).
> 
> We decided earlier that migrations for 3.x have to be very minimal
> or unneeded. So if a lot of tidy work needs to go into them we are
> probably dealing with 4.x material anyway.

Sure, good point, but there's always a fair amount of polish that needs 
to go in at the end.

> I don't think we can do time-based releases without this requirements.
> And I consider those important for 3.x releases. Perhaps we can try
> separate PLIP-approval and implementation-approval decision points to
> reduce your risk.

Good idea. But from past experience, the framework team will be the 
first people to really review code being proposed. That in itself is a 
very good thing. A fresh pair of eyes or two will always mean some good 
recommendations. If we don't encourage such recommendations and give 
people time to react to them, we're losing out on a QA opportunity.

> That would put the release at end of april / begin of may. That is 9
> months after 3.0, which is a very long time for what should be a small
> release. I think we can do a 3.1 and 3.2 during that period. Smaller
> steps are a lot simpler to manage as well: they reduce the load on the
> framework team, they reduce the risk of stability problems and they
> are simpler to test.

I agree - hopefully we can shorten things down (but please don't expect 
much to be done in December). However, the fact that it's 9 months after 
3.0 is kind of irrelevant. The question is how far it is from when the 
announcement is made. Until a few weeks (or months) ago, we weren't even 
clear that there was going to *be* a small release, and people were 
focused on larger items for 3.5 or (more likely) doing nothing awaiting 
a process to start.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book