Mark Phippard wrote:
> 2008/5/22 Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>:
>
>> The dates I proposed initially were based upon the release process as
>> defined in STATUS, nothing more. I was just trying to give people a heads
>> up to avoid any surprises when I cut the final RC. I'm flexible, and as of
>> right now I *am not* planning on cutting the RC this weekend.
>
> FWIW, your own availability to do it not withstanding, I do think we
> should try to reach consensus on one of the options soon and should
> try to do something this weekend. All of the options involved making
> something for next week. That said, if the weekend is spent clearing
> STATUS or deciding what to backport then that is fine too. Let's just
> keep moving in some direction.
Not rolling this weekend has nothing to do with my availability, but
rather it just feels like there's still a lot of churn in STATUS. I'd
like to let things settle a bit, and then roll. If that happens by this
weekend, fine by me; we'll have an RC this weekend.
(Speaking of availability, I'll be AFK June 12-15. Given the timeline,
we could be in the middle of rolling 1.5.0 by then. Not that I'm the
guy that has to do it, I just want folks to know so somebody else can be
prepared.)
>> I think that a number of people were assuming that RC 5 would become 1.5.0.
>> That's never been my understanding; I've been working under the assumption
>> that RC 5 would allow people to discover problems and contribute
>> conservative bugfixes, and that RC 6 would be rolled a week before 1.5.0,
>> per HACKING. Because of our self-policing, we should be able to roll an RC
>> 6 at any time after RC 5.
>
> So can you just specify which of the 3 options you are personally in
> favor of? It sounds like option #2, which is let's do an RC6 but
> let's only include the conservative bugfixes.
Personally I'm leaning toward option 2.5 :) I think options 2 and 3
both have merits, but they both have drawbacks, too. The fixes
currently on 1.5.x need testing, and that could happen during an
extended soak, or as part of the runup to 1.5.1.
>> Theoretically, 1.5.x is only becoming more stable as we progress. I remain
>> unconvinced that this is the case. I think a lot of people (myself
>> included) have merged more than conservative bugfixes and showstopper
>> problem fixes to 1.5.x since RC 5. I think we need to exercise a bit more
>> restraint here, and Karl's review of stuff merged since RC 5 is a step in
>> the right direction.
>
> Other than some of the API changes, which are more about code
> maintenance, I am not aware of anything that is a showstopper. There
> are some non-trivial bug fixes that have been backported, but they are
> also were not release blockers.
>
>> If we do roll RC 6, and then give it a two-week "soak", per HACKING, it's
>> really only a one-week soak, because of RC 7 coming a week before the end of
>> the two weeks. RC 7 would then become the final. The alternative, IMO is
>> to roll RC 6 early next week, and deem it the precursor to 1.5.0, but wait
>> two weeks to find showstopper bugs. Anything besides a showstopper bugfix
>> would be pushed to 1.5.1. RC 6 would then become 1.5.0 around June 9.
>
> I do not believe we have to do an RC7. An RC7 would only be necessary
> if there were some bugfixes made after RC6 that we felt HAD to go into
> the release.
True. The point of the RC-one-week-before-final is to pick up any
conservative fixes made during the soak, and to set the magic revision
for the final tarball. We could easily decide that RC 6 serves that
purpose, and just give it more than 1 week. I've no problem with using
RC 6 for this purpose.
-Hyrum
Received on 2008-05-22 17:08:12 CEST