The window of Monday through Wednesday sounds like a great target. Nothing
says that the first RC has to be final. If whoever is doing the branch wants
to do it on Monday rather than Tuesday, fine. If one or more of these nasty
"blockers" gets fixed on Tuesday, we should still be open to a re-spin to
put quality over a mere day or two of delay. But draw a hard line on
Wednesday.
-- Jack Krupansky
-----Original Message-----
From: Mark Miller
Sent: Thursday, January 10, 2013 3:36 PM
To: [email protected]
Subject: Re: 4.1 release
Saying tomorrow without any date that gives anyone any time to do anything
is out of nowhere to me. People in Europe and east of that will wake up and
find out, oh today. While pressure has been building towards a release, no
one has proposed a date for a cutoff. I think that is always only fair. I
think that if you were desperate to cut off to blockers tomorrow, you should
have called for that last week.
Robert Muir's short term releases are not threatened by allowing people to
plan and execute a release together. You can take that too far and do damage
from the opposite direction. Giving people time to tie things up with a real
deadline is only fair. We all know a nebulous deadline is not conducive to
finishing up work.
I think all releases should have a known date that we agree on that gives
developers some time to finish what they are working on or what they believe
is important for the release. At a minimum there should be a few days for
this. A weekend involved only seems fair. This doesn't have to be a long
time, but it should not require we file blockers and just seems like a
friendly way to develop together.
Monday is fine by me if others buy into it.
Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out
another month. But let's not do the reverse and release it tonight. The
sensible approach always seems like we should plan out some target dates on
the list - dates that actually give devs a chance to respond to - and then
follow through on those dates.
- Mark
On Jan 10, 2013, at 3:26 PM, Steve Rowe <[email protected]> wrote:
Okay - I can see your logic, Mark, but this is not even close to out of
nowhere. You yourself have been vocal about making a 4.1 release for a
couple weeks now.
I agree with Robert Muir that we should be promoting short turnaround
releases. If it doesn't make this release, it'll make the next one, which
will come out in a relatively short span of time. In this model, Blocker
issues are the drivers, not "Fix Version". If people want stuff in the
release, they should mark their issue as Blocker.
How about a compromise - next Monday we branch and only allow Blockers to
block the release?
Steve
On Jan 10, 2013, at 3:08 PM, Mark Miller <[email protected]> wrote:
-1 from me - I don't like not giving people a target date to clean things
up by. No one has given a proposed date to try and tie things up by -
just calling 'hike is tomorrow' out of nowhere doesn't seem right to me.
We have a lot of people working on this over a lot of timezones. I think
we should do the right thing and give everyone at least a few days and a
weekend to finish getting their issues into 4.1.
- Mark
On Jan 10, 2013, at 2:36 PM, Steve Rowe <[email protected]> wrote:
I'd like to start sooner than next Tuesday.
I propose to make the branch tomorrow, and only allow Blocker issues to
hold up the release after that.
A release candidate should then be possible by the middle of next week.
Steve
On Jan 10, 2013, at 2:27 PM, Mark Miller <[email protected]> wrote:
On Jan 10, 2013, at 2:12 PM, Steve Rowe <[email protected]> wrote:
I'd like to release soon. What else blocks this?
I think we should toss out a short term date (next tuesday?) for anyone
to get in what they need for 4.1.
Then just consider blockers after branching?
Then release?
Objections, better ideas?
I think we should give a bit of time for people to finish up what's in
flight or fix any blockers. Then we should heighten testing and allow
for any new blockers, and then kick it out. If we need to do a 4.2
shortly after, so be it.
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
