I'd also like for Simon to have a chance to look at this bug: https://issues.apache.org/jira/browse/LUCENE-4676
I know he isnt back until next week... On Fri, 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]
