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]
