[Framework-Team] Re: proposed plone 3.1 timeframe
lists at tomster.org
Wed Nov 21 23:54:36 UTC 2007
from following martin's and wichert's thread so far, i'd like to pick
up the idea of doing a 3.1 and 3.2 release in relative quick
succession by the same framework team.
in effect, we would be splitting up what is currently envisioned as
3.1 into two separate releases. this would enable us to keep 3.1 (i.e.
the 'first' 3.1) manageable and get it out the door in a timely manner
(i second martin's proposal of a timeline, where we keep christmas a
holiday - i know i will be with my family ;-)
anybody not getting their plips into 3.1 needn't fret, because 3.2 is
just around the corner.
also, swinging it this way could end up as a possible insurance, in
case the 'big 4.0' is starting to run late. we could incorporate
further non-invasive features (i.e. things that could go into 3.1 but
haven't been conceived of just yet) and ship 3.3 or even 3.4
On 21.11.2007, at 23:45, Martin Aspeli wrote:
> 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
>> 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 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
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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
> Framework-Team at lists.plone.org
More information about the Framework-Team