On Fri, Jan 11, 2013 at 1:52 PM, Robert Muir <[email protected]> wrote: > I'd also like for Simon to have a chance to look at this bug: > https://issues.apache.org/jira/browse/LUCENE-4676
I will take a look next week! simon > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
