I suggest you stick this on the Wiki and make it more official if people +1 this approach. Otherwise it will get forgotten and will be hard to reference.
Otis ---- Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Lucene ecosystem search :: http://search-lucene.com/ ----- Original Message ---- > From: Upayavira <[email protected]> > To: [email protected] > Sent: Mon, May 30, 2011 5:10:54 PM > Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 > > Watching the various wishes on this thread (release early, release > often; I want feature X included in the release; etc), I'd propose this > for an approach that I believe could cover all bases: > > * Anyone can propose a release > * They should give n days warning (suggest 1 wk) > * Ideally, a code freeze happens after n/2 days: > * an RC is created at this point, to aid testing > * only bugs/regressions found in RC will be committed > * if others want to continue coding, a release branch can be > created > * if anyone commits code between 0 and n/2 days, they also commit to > fixing reported bugs between n/2 and n days > * Proposer can then roll the release and call for a vote when n days > are up, assuming they are happy that all reported bugs are resolved > > Getting a little more formal, we could have suggested approximate dates > on calendar, and folks could volunteer to take on those releases, > following the above process. > > This would give folks warning to get code in that is 'nearly' finished, > yet prevent the release waiting on 'nearly finished' code. It would also > put most of the power to make the release into the hands of the release > manager. > > Thoughts? > > Upayavira > > > On Sat, 28 May 2011 17:09 -0400, "Grant Ingersoll" <[email protected]> > wrote: > > I think I kicked off the 3.2 release discussion back a bit saying it's > > been about 3 mos (come June). To me, roughly every 3 months or so is > > ideal. > > > > I'm thinking about setting up a Google calendar that we can put reminders > > on (as well as other Lucene related events) and then share it publicly > > (committers would have write access) > > > > > > On May 28, 2011, at 9:49 AM, Mark Miller wrote: > > > > > The cost of the overhead is paid by volunteers - there is no *need* to >release every month. But if someone is so concerned that a few features have >not made it in this release that are important - there is no reason not too >as >well - given that the person is willing to roll the release. > > > > > > > Releases take 3 +1s - I'll give my +1 as often as someone puts artifacts >in front of me and I have time to verify them. > > > > > > > The worry of releasing TOO much is so premature it's not even funny :) > > > > > > Sent from my iPad > > > > > > On May 28, 2011, at 1:25 AM, "David Smiley (@MITRE.org)" ><[email protected]> wrote: > > > > > >> Clearly a year+ is too long to release, and thankfully it appears > > >> that's >in > > >> the past for Lucene/Solr. But on the other extreme, one can release too > > >> quickly as well, of course. There is overhead to performing the release > > >> itself. Consequently there should be enough "goodness" in the release >to > > >> make it feel worthwhile. And because we value stability and robustness in > > >> Lucene/Solr, changed code should have *some* amount of time to be > > >> potentially used and tested further. And there's impact on the user > > >> community. If a release occurred too frequently then there might be very > > >> little meaningful improvements in the release. I believe it is Hudson >(now > > >> Jenkins) that followed that extreme of I think releasing every week or >so. > > >> It's so frequent that as an admin of such a server where I work, I don't > > >> even care to look at what's new in the releases because there are too >many > > >> of them--I've become apathetic when I was initially excited to use it. So > > >> hopefully with each release there's something truly cool to tell others > > >> about in Lucene/Solr. > > >> > > >> Gauging these factors is of course very subjective. Personally, I > > >> think >3 > > >> months is just right, 1 or less is too fast. Given that v3.1 was > > >> released >2 > > >> months ago and there are some truly cool features like Result Grouping >in > > >> Solr to announce in 3.2. I'm in favor of a release. > > >> > > >> ~ David Smiley > > >> > > >> ----- > > >> Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book > > >> -- > > >> View this message in context: >http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2995419.html > > > >> Sent from the Lucene - Java Developer mailing list archive at >Nabble.com. > > >> > > >> --------------------------------------------------------------------- > > >> 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] > > > > > > > -------------------------- > > Grant Ingersoll > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > --- > Enterprise Search Consultant at Sourcesense UK, > Making Sense of Open Source > > > --------------------------------------------------------------------- > 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]
