[Framework-Team] Re: release schedule changes

[Martin Aspeli]

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

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

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

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

Martin