Re: proposed 2.2 release schedule

[Luis Villa <louie ximian com>]

On Thu, 2002-08-08 at 10:32, Glynn Foster wrote:
> In general, I think the schedule seems perfectly sane - it's a bit
> easier to see the graphical representation on my whiteboard - we should
> try and do this for the next time maybe? ;)

You're volunteering to take a picture of the whiteboard? :) 

> > *The marketing team feels strongly that we should aim for mid-January so
> > that we can announce at LinuxWorld New York, which would be pretty cool.
> > Much of the rest of release team is worried about hackers and their
> > availability and willingness to hack during January. It's a noble goal-
> > if we believe we can hit it. Thoughts/comments?
> 
> Yeah, I think mid January is probably pushing it somewhat, considering
> most hackers won't want to spent their Christmas dinner with a laptop in
> their hands. 
> 
> Currently we have mid December to early January slotted in for bug
> fixing, so we're effectively discounting nearly a month of that time due
> to the holiday period - that worries me slightly.

I hope that the New GNOME (where Quality is Job 1, or something like
that ;) won't have all that many bugs to fix at that point in the cycle.
That's probably wildly, stupidly optimistic but I hope I'm right :) 

> I think [and there seems to be general agreement] to make the 5 month
> release cycle into 6 months...perhaps having another month of bug
> fixing. Alternatively, and mabye this isn't a good idea, we could extend
> the period of 2.2 hacking to the end of November.

Don't think of it as a 5 month cycle, think of it as a seven month cycle
(Jun. 26th-> Jan. 26th.)

> Either way, I think pushing for mid January is probably a little
> ambitious and we haven't even discussed the possibility of a slip yet :/

<nod> I want to make clear- I'm suggesting mid-January as a _target_.
I'll be the first one to scream really, really, really loud if we don't
have quality and we're pushing to release anyway. 

> > *This doesn't touch the issue of API freezes for core libraries; /if/ we
> > think this is going to actually be an issue then we really need to
> > address it. 
> 
> There was a discussion at one of the recent release team meetings about
> having a tiered freeze, starting at the lower level libraries and
> gradually freezing them right the way up - this is probably a non-issue
> for 2.2 since the API is well defined by now, but perhaps we could adopt
> this process for future cycles?

Havoc? I know this has been something you've been concerned about in the
past... thoughts? 

> > *Release numbering- what do maintainers think about numbering their
> > releases based on the gnome release? i.e., 2.1.1.0 for the release that
> > goes out with GNOME 2.1.1, 2.1.1.1 for the first snap release after
> > 2.1.1, etc.? This is really sort of micro-managerial so we're reluctant
> > to ask this, but it would help packagers and general organization. 
> 
> Okay, I think this will have to be a GEP at this stage. I'm not entirely
> sure if I like this [or care for that matter] but apparently it does
> confuse the users who are testing the tarballs. Perhaps something could
> be done at the FTP organization level to solve this. Michael, comments
> on using GEP here? :)

Agreed that this should probably be a GEP. Fredric, Michael, anyone care
to write one up? 

> > *We need to think about criteria for the 2.0.x series and its releases
> > in a separate discussion, IMHO, but it definitely needs to be talked
> > about- who is going to do it, when it will be done, how we decide when
> > it will be done, etc.
> 
> I assume we're talking about 2.0.x for x > 2, right? I think we've
> pretty much agreed on a schedule for up to that. I'm not entirely sure
> what we can do here - obviously if we want it to be maintained we need
> people to hack on it...and I'm pretty curious to see if anyone will run
> with the ball here...

Right. Definitely x > 2. Sun, RH, Ximian, this is probably your ball to
carry, to a certain extent; your feedback is welcome.

Luis