I thought you had already volunteered actually, but yes +1 On Fri, Jan 11, 2013 at 12:53 PM, Steve Rowe <[email protected]> wrote: > 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] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
