Wichert Akkerman wrote:
- January 7th : final bundles merged
- January 21st : first beta release
- March 11th : first release candidate
- April 23rd : release
And here is a problem: I learned this week thatthere is a UI sprint
scheduled for February. I do not want to see any non-small changes in
the beta stage, UI or otherwise. So we can do two things:
1. only pick the small changes that result from that sprint and include
those. Everything else will be an excellent start for Plone 3.5.
2. postponse 3.0 further. This means that we can't go beta until end of
February, more likely early march. I don't expect to see any UI work
fully finished before then.
Talking with limi he appears to be in favour of the second option: he
considers it critical that 3.0 has a very polished modern UI. Personally
I have a slight preference for the first option: we have landed an
awesome amount of changes and can still keep a healthy release schedule.
This mis-match had kind of gone by me...
I am thinking we need to be stricter about the alternating
infrastructure and UI releases in the future: currently we are still
doing both infrastructure and UI in a single release. The infrastructure
changes are landing close to the merging deadlines and the UI is not
being done until after the infrastructure has landed. This means the UI
is being done too late and jeopardizes the release schedule.
I think you have a good point. Often, it is easier to do UI once the
code has been accepted "in principle" and merged into trunk, because UI
tends to have more interdependencies, but also because UI deficiencies
often are not discovered until people (esp. limi and co) have used the
code a bit, and expecting people to try out all bundles regularly is not
I think the UI/infrastructure dichotomy is a false one. No new feature
should have a crappy UI. Plone stands out from the rest in large part
because we don't let user-unfriendly and inconsistent UI pass (too
often). I think a better way to think of it is "end-user focus" vs.
"developer focus". 3.0 is very much end user focused; 3.5 should be much
more about tools that integrators and developers need, as well as
under-the-hood stuff like improving our indexing and searching
A lot of 3.0 needs a tight pulling together in the UI stage, and a lot
of work (I know both the portlet and content rule management UI does,
and I am fully expecting to dedicate the UI sprint to these two). From
2.1, we learned that a lot of this happened at the (first) UI sprint,
and from the way the UI sprint was run. I don't think it's an acceptable
option to say "we'll give you the functionality in 3.0, but you'll have
to wait 9 months for 3.5 to get a UI that isn't lame".
That said, I don't think it's terrible to see strong UI improvements
after the first beta. At the beta stage, we expect more testers, so we
can get their feedback into the UI. I agree that looking at the dates,
though, we may need another couple of weeks (I really don't think it's
more than that) before we start talking RC.
For the future - I think we need to start planning our sprints and our
release cycles together. The way it's shaping up, it looks as if the
Amsterdam sprint (Feb 17-20) will be about fixing up a lot of the UI
turds and loose ends from the bundle frenzy. Sorrento (Mar 27-Apr 3)
will be about fixing bugs, tying up remaining lose ends and getting 3.0
into a releasable state. Take away the sprints and I don't think either
Organising sprints takes some effort and planning, as does getting the
best people to them. But we know that the best work happens at sprints.
I think it'd be wrong to let a (somewhat arbitrarily decided) schedule
override the realities of what we can expect to achieve when we have
many our best people in the same place for 5-7 days, and for the sake of
our users and for making Plone better, we should work around that. (And
next time, timetable sprints for specific purposes in the release schedule).
+1 to delay, by 2 about weeks, the first RC. I wouldn't mind that
meaning we get 2 more weeks of beta, but then I'm not so hung up on the
alpha v beta distinction. :)
Framework-Team mailing list