On #lucene IRC, Robert Muir wrote "i'm not RM this time" I volunteer to be the 4.1 RM.
Steve On Jan 11, 2013, at 7:50 AM, Erick Erickson <[email protected]> wrote: > P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they > want and cut the first RC early next week.... > > > On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson <[email protected]> > wrote: > I'll take are of SOLR-4112 this morning, probably create another JIRA to > track unit tests. There aren't any today and I have evidence from the field > that it makes DIH usable so.... > > Erick > > > On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky <[email protected]> > wrote: > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
