Thanks nobel! can you please ping me here so I can kick off another RC. Regarding the bugs that should / should not block a release I think it's hard to say which one should and that is my biggest problem here. I think with more frequent releases and more point releases we can make the intervals shorter and bugs get fixed quicker. I think it's also the responsibility of the other committers to maybe go back a step and ask themself if a bug should block a release and only if the are absolutely +1 on respin mention it on the release thread? To me as a RM it's really hard to draw the line. I also think we should not push stuff into the release branch unless it's the cause of the respin, we should work towards a stable branch an every change makes it less stable again IMO.
just my $0.05 On Fri, Feb 21, 2014 at 6:35 PM, Noble Paul നോബിള് नोब्ळ् <[email protected]> wrote: > I'm working on a test case for 5762 I'll commit it tomorrow IST > > On 21 Feb 2014 20:05, "Simon Willnauer" <[email protected]> wrote: >> >> So the problem here is where to draw the line. I think in a setup like >> we have with lucene and solr in one codebase the chance to hit a bug >> within these 72h is huge. This means the Release process is a huge >> pain each time. Then we have bugs that justify a respin and some who >> don't. I looked at SOLR-5762 and it seems this one should cause a >> respin but the LUCENE-5461 doesn't. It's hard to draw that line since >> its pretty much up to the RM and then you get heat if you draw that >> line. IMO we should improve our release process and release a point >> release every week shortening the vote period for that to maybe 24h. >> That way we can get stuff out quickly and don't spend weeks on the >> release process. >> >> I will call this vote here as failed and build a new RC once SOLR-5762 is >> in. >> >> simon >> >> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <[email protected]> wrote: >> > I volunteer to be 4.7.1 RM. >> > >> > I’d prefer to delay the 4.7.0 release to include all known bugfixes, >> > though. >> > >> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and handle >> > any respins. If not, it’s your prerogative to continue with the current RC >> > vote; others can express their opinions by voting. I’m sure it’ll be fine >> > either way. >> > >> > Steve >> > >> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer <[email protected]> >> > wrote: >> > >> >> Guys, I don't think we will ever get to the point where there is not a >> >> bug. But we have to draw a line here. If we respin I have to step back >> >> as the RM since I just can't spend more than 7 days on this. I think >> >> there should be a 4.7.1 at some point where you can get your bugs >> >> fixed as everybody else but we have to draw a line here. I think I am >> >> going to draw it here with the 3 +1 I am having. >> >> >> >> simon >> >> >> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe >> >> <[email protected]> wrote: >> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My >> >>> understanding is >> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or >> >>> earlier? >> >>> >> >>> >> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <[email protected]> wrote: >> >>>> >> >>>> >> >>>> And I think it should be under optimizations not changes in behavior. >> >>>> >> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen >> >>>> <[email protected]> wrote: >> >>>>> >> >>>>> >> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second >> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399 >> >>>>> instead of >> >>>>> LUCENE-4399. >> >>>>> >> >>>>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> 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]
