Re: 2.20 schedule

["Elijah Newren" <newren gmail com>]

Hi Andre,

Thanks for working on this.  I have lots of comments, as you requested, below.

On 3/7/07, Andre Klapper <ak-47 gmx net> wrote:
> boy, this time it's really non-trivial. before doing this, i've dreamt
> of having the api/abi freeze one week earlier so everybody has enough
> time to fix build breaks. but reality can bite...

yeah, it looks like we have some nasty tradeoffs...

> guadec is very late this year. i think everybody agrees that already
> being under api/abi freeze at guadec would be a huge motivation killer
> that definitely has to be avoided.

This sucks.  A lot.  Personally, I think the best way to fix it is to
push make our schedule a week longer than normal.  Thus, your Sched3
plus 1 week (both your Sched1 and Sched2 are compressed schedules, as
was our 2.15 cycle despite my vote to not compress it).

> the other constraint is the opensuse 10.3 release which is planned for
> the end of september (the final date is not fixed yet), and they would
> love to include gnome 2.20 if possible.

I'm with Kjartan in thinking that our schedule should not be adjust
just for the distros.  Even if we did bend for the distros, if I
recall correctly, opensuse used the 2.12 release of GNOME when the
2.14 release had been out already for about 2 months.  So would
pushing things to release early even help get them to use it?

(I really would rather get it out in time for the distros when/if they
said they've wanted to include it.  Thus Frederic's email makes me
hesitate a bit about this, but I really think compressing the schedule
would probably be worse; our 2.13, 2.15, and 2.17 schedules have all
been messed up due to the combination of GUADEC and people not wanting
freezes soon after Christmas break -- it'd be nice to solve this
problem finally by using a full 26-week schedule and then extending it
by a week as well.)

> feedback, now!

Okay.  As I mentioned above, I'd really like to get the spacing of
events fixed a bit and break the cycle of slightly broken schedules.

Schedule preferences:
- I dislike the huge compression of schedule Sched1 (loses two weeks
from the release schedule; I know 2.15 did that too but I complained
about it last year too)
- I dislike the slight compression of schedule Sched2, and the dropped
2.19.90 release.
- Sched3 looks the best to me, but I have several other comments below about it.

Gripes with timing/spacing
- Module inclusion discussion heats up 3 weeks before we are supposed
to meet and decide?  I'd prefer 1 week.
- I dislike feature & UI freezes coming at the same time.
- As J5 pointed out last year, many will be travelling right after
GUADEC and requiring a release immediately after might be problematic.
- I think we could fix this all by adding one more week.

Layout:
- I found it confusing that you didn't include weeks with no event
(e.g. week 24 on Sched3).  Traditionally we have always included it,
and thus while reading on the right I tend to count line separations
to get week counts.  Compare http://www.gnome.org/start/2.11/ and
http://live.gnome.org/TwoPointFifteen
- You were probably trying to clear things up by putting the freeze
dates clearly on the tarball due dates.  However, it made week 18 and
the beginning of week 19 kind of look like one week at first glance; I
thought it made API/ABI freeze happen during GUADEC.  Perhaps we can
find a week to get bolder lines between weeks, or lighter lines
between events on the same week?

My suggestions (modifications to Sched3):
- Move the following one week later:
  - API/ABI freeze
  - New APIs must be fully documented
  - UI Freeze & everything that comes after it
- Move the following one week earlier:
  - Feature and Module Freeze (to coincide with API/ABI freeze)
- Move the following two weeks later:
  - Module inclusion discussion heats up

Advantages:
 - Two weeks between feature & UI freeze
 - Allows some time after GUADEC before API/ABI freeze so that
hackers on the core have time to fix up (minor) issues hashed out at
GUADEC
 - Allows the module discussion to start just after GUADEC, probably
the best time for it
 - Won't require a release immediately after GUADEC when some
maintainers are travelling


Anyway, that's my nit-picky list.  Feel free to discuss, object,
vote-down, etc.  :)

Elijah