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]

Reply via email to