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
any thoughts?
cheers,
tom
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
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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
