Previously Martin Aspeli wrote: > Wichert Akkerman wrote: > >Now that we have a new framework team it is time to start planning the > >3.1 release. 3.1 is intended to be a low-risk upgrade which can follow > >the 3.0 release quickly. The release cycle has to be short so we can > >get things out to people. Here is my proposal: > > > >- all proposed updates for have to be submitted by christmas > >- framework team finishes reviewing by january 9 > >- accepted changes are merged in the days after that > >- first pre-release for 3.1 happens on january 15 > >- final release for 3.1 happens first half of february > > > >In order to make reviewing simple all updates have to be submitted in > >the form of a working buildout. And to keep the 3.1 process smooth they > >have to include all migrations, finished user interfaces and > >documentation. We will not do any polishing after merging - that has to > >be done beforehand. > > > >Judging by the current activity I expect there to be only 2 or 3 > >proposals in a mergeable state. That is not much, so you should be able > >to enjoy some christmas vacation as well :) > > I think you should set a threshold here. Doing a release for only 2 or 3 > proposals may just be too much work for everyone to be worth it. That > is, unless we aim for a quick 3.2 as well (in which case I suggest this > team stays on for that release as well to keep the overhead of finding a > new team down).
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. 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. > 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 > 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. 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. > That's a roundabout way of saying I think these deadlines are > unrealistic. :) > > I'd suggest: > > - Demanding PLIPs (text only) in two-three weeks - this focuses people > and allows you to give direction on how useful or appropriate a feature is. > > - Giving people till mid-January (in effect, respecting the Christmas > as a holiday, not Ploniday) to get review buildouts in shape. > > - Reviewing buildouts based on functionality with fresh sites (so no > testing of migration), and giving some leeway on UI and other polish. > > - Doing your reviews very quickly (this was a problem last time around > - it took several weeks to get through all the bundles). > > - Giving feedback to authors on what they need to do to reach > "mergeable" state. > > - Setting a second deadline about a month after your voting completes, > when approved buildouts have to be mergeable. This should include > reacting to feedback you give (e.g. suggested/required improvements). > [.. snip ..] > - Doing a 3.1 alpha two weeks after that, to allow the merge to settle > down, and then go through a quick beta phase before reaching rc, again > for about a month. 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. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
