lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: [VOTE] Release Lucene/Solr 3.2.0
Date Tue, 31 May 2011 01:04:02 GMT
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 <uv@odoko.co.uk>
> To: dev@lucene.apache.org
> 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" <gsingers@apache.org>
> 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)" 
><DSMILEY@mitre.org> 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: dev-unsubscribe@lucene.apache.org
> >  >> For additional commands, e-mail: dev-help@lucene.apache.org
> >  >> 
> > > 
> > >  ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >  > For additional commands, e-mail: dev-help@lucene.apache.org
> >  > 
> > 
> > --------------------------
> > Grant  Ingersoll
> > 
> > 
> > 
> > 
> >  ---------------------------------------------------------------------
> > To  unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >  For additional commands, e-mail: dev-help@lucene.apache.org
> > 
> --- 
> Enterprise Search Consultant at Sourcesense UK, 
> Making Sense of  Open  Source
> 
> 
> ---------------------------------------------------------------------
> To  unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For  additional commands, e-mail: dev-help@lucene.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message