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].**org<[email protected]> >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> [email protected].**org<[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> [email protected].**org<[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> [email protected].**org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> [email protected].**org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> [email protected].**org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> >
