Hey Guys, (sorry for the top post)
There's no reason to freeze trunk during releases. In fact, during the RC, once the branch (or tag for that matter) is created, trunk can continue on, no need to stop. Heck, we can always just tag or branch from a specific revision too so it's not really a biggie. Cheers, Chris On Jun 21, 2012, at 2:43 PM, Lewis John Mcgibbney wrote: > Hi Markus, > > On Thu, Jun 21, 2012 at 10:02 PM, Markus Jelsma > <markus.jel...@openindex.io> wrote: >> It's still not clear to me what 1.5.1 is going to look like. Will it be >> current trunk incl. the script bugfix or just 1.5 plus the bugfix? I would >> vote for the latter as it makes more sense for a bugfix release. > > I am easy on this one... I suggest we do it the normal way. Lets let > folks chime in and see where we are on Saturday. It looks like 2.0 is > going to be shifted with the new commits so do we wish to try and keep > at least the minimal consistency between both releases? > >> >> There is another debate behind this, in my opinion, about freezing trunk >> prior to releases and thus stopping active development. This has been an >> issue in the past. Is this something for another thread? >> > > Yeah I must also agree that we should branch trunk, keep the branch > for the release then run the RC's from the branch regardless of how > trunk comes on. My only suggestion for backporting patches from trunk > to the release candidate branch is if it is a pretty critical bug fix > as we've now discovered in 1.5! > > Additionally there is another note here as well w.r.t release > managers. We've relied on the excellent work done by Chris (and > others) as RM's for a number of releases but during the release period > (on occasion, more recently) as you mention trunk has frozen > temporarily. Of course it is the aim to prevent this happening should > the RC not progress as we would all like. Hopefully we are moving > towards a more adaptable and sustainable RM process within Nutch where > the RM responsibility can be undertaken/overseen by more than one > individual over the entire duration of the process. I think (and hope) > we can consider the slight struggle we've had for 1.5 as an exception. > As far back as I can remember RC's have always been efficient and > smooth and I personally am committed to ensuring we return to the high > precedent set by previous RM's. > We've also seen an alternative (and in my opinion an improved) > publication of Nutch atrifacts for 1.5. For reference I direct you to > Julien's commentary [0] on this topic. Due to this, we've had to run > additional RC's which has taken a bit longer than usual and I must > personally apologise to everyone for at least one RC cock up which > could have been avoided had I been more familiar with the Nutch > specific release process. > > I think I'm ranting here so I'm going to give it a bye now. > > Lewis > > [0] http://digitalpebble.blogspot.co.uk/2012/06/whats-new-in-nutch-15.html ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
