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
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
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.
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
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.
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