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


_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to