Re: 2.15.x schedule first pass

["Elijah Newren" <newren gmail com>]

On 3/13/06, John (J5) Palmieri <johnp redhat com> wrote:
> On Mon, 2006-03-13 at 14:07 -0700, Elijah Newren wrote:

> > - Why four weeks between 2.15.3 and 2.15.4?  (I know we did 3.5 weeks
> > or so for 2.11 but that was due to relocation of the gnome servers; we
> > originally had planned for just 3 weeks)
>
> The timing of GUADEC means if we have a release in that time it would
> have to happen during GUADEC which is a time we would want most of our
> developers to be hacking, having fun and talking about more important
> things (at least when we have them face to face) than a point release.
> Notice that GUADEC is a week long this year.

Not quite; the natural time (according to the past few releases) would
be July 3rd (3 weeks after 2.15.3, instead of 2 or 4)...

> We could have a release on July 3rd when theoretical everyone would be
> back to their usual grind (though some will have taken the time after
> GUADEC to travel more).  The problem with this is we slip everything
> down an extra week.

It doesn't slip everything by a week; July 3rd would be the normal
schedule.  Note that you've shortened the 2.16 schedule by a week by
removing what normally would be the two week 2.15.5 release and then
adding one week to 2.15.4 release.

> Not a big deal but does the extra release actually
> help or just add more of burden?  I suspect a lot of hacking is going to
> go on a GUADEC this year.  Do we do a release directly after or do we
> let everyone go home, look over their work and polish it a bit and then
> do a release a week later?

Yeah, that makes sense.  I can see how this might cause problems. 
Perhaps someone can come up with suggestions that will handle that
problem as well as the potential problems/annoyances I see with the
current proposal?  The potential problems I see are:

1) If the 2.16 schedule is shortened by a week as you propose then we
run into the feature-freeze-too-soon-after-Christmas problem during
2.18 again.  I think we should add the extra week back in somewhere.

2) To me at least, it seemed a little odd to have
API/ABI/Feature/Module and UI freeze all lumped together.  It already
seemed like we had too many freezes at once.  Maybe I'm just odd,
though?

3) Due to a late GUADEC and a shortened schedule, we're giving people
even less time to implement any cool ideas that come out of the
meeting.  This is mostly inevitable, but 4 vs 3 weeks before feature
freeze might be enough of a difference that we want to consider.

Granted, I mostly mentioned #2 and #3 because I think it makes the
case for #1 stronger, which is the point I'm most interested in
(because then scheduling becomes easier for both us and others with
just 6 month shifts occurring in most cases after that).  But, #2 and
#3 might be important to others, so it can't hurt to bring them up. 
;-)