Hi, On Tue, Jun 29, 2010 at 11:49, Julien Nioche <lists.digitalpeb...@gmail.com>wrote:
> Thanks Chris, > > I already shared my thoughts on this yesterday, but I still fail to see the > advantage of keeping the details of the recent github nutchbase commits > (some of them being just upgrades to the recent changes in 1.1) in svn > nutchbase knowing that the point is actually to do incremental changes to > the existing trunk (which already has the 1.1 changes) from svn nutchbase > and review / comment / improve the code on this occasion. > > Since we also want to produce a patch in JIRA for the changes in svn > nutchbase in order to put the "donated to Apache" stamp on it it would make > sense to do that just once and not for all the commits which have been done > in github. > > I am probably missing an important point here, but if so I would appreciate > if someone (Dogacan?) could explain why we should not stick to the original > plan > (a) clear the existing svn nutchbase > (b) generate a large patch with the code from github and JIRA it Do you mean generating a single patch vs nutch? There are a lot of fixes and improvements in nutch 1.1 that I cherry-picked to nutchbase later. If we generate a larger patch, and then this branch is blessed as "trunk" then history for those improvements will be lost. Or am I misunderstanding you here? > (c) commit the changes to svn nutchbase > then get on with the interesting bits. > > My concern is that proceeding as Dogacan described yesterday might take > quite some time and block the rest of the work on 2.0. I am happy to work on > the 3 steps above BTW. > > Thanks > > Julien > > > > > > On 29 June 2010 06:44, Mattmann, Chris A (388J) < > chris.a.mattm...@jpl.nasa.gov> wrote: > >> Okey dokey guys, (c), (e) and (g) are done. >> >> Julien, Doğacan, your turn on (a) and (d) and then we can all work on (e) >> and (f)... >> >> Cheers, >> Chris >> >> >> >> >> On 6/28/10 12:55 PM, "Doğacan Güney" <doga...@gmail.com> wrote: >> >> On Mon, Jun 28, 2010 at 20:23, Andrzej Bialecki <a...@getopt.org> wrote: >> >> On 2010-06-28 17:57, Mattmann, Chris A (388J) wrote: >> > Hi Doğacan, >> > >> > So your proposition is to combine (a) and (b) then? That’s fine by me, >> > so long as there are no objections from others. I can still move forward >> > with , (e) and (g) then... >> >> >> No objections from me - but IMHO to satisfy the legal minds you still >> need to produce a patch and attach to an issue with the "Grant to ASF" >> checkbox marked... >> >> >> OK, I'll create a new issue in JIRA, and then attach a lot of patches :) >> >> I'll try to appropriately mark patches that are straightforward ports from >> nutch 1.1 >> into nutchbase so that the same committers can commit those patches >> _again_ >> hopefully preserving post nutch 1.0 history as much as possible. >> >> >> (Also, I always shudder when I imagine a massive merge failing ... but >> that's probably a leftover from my CVS days when a failed merge would >> leave a completely broken tree.. ah, well, good luck :) ). >> >> >> I regularly do large merges in git and it works beautifully. We'll see how >> well >> SVN does :) >> >> >> >> -- >> Best regards, >> Andrzej Bialecki <>< >> ___. ___ ___ ___ _ _ __________________________________ >> [__ || __|__/|__||\/| Information Retrieval, Semantic Web >> ___|||__|| \| || | Embedded Unix, System Integration >> http://www.sigram.com Contact: info at sigram dot com >> >> >> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Chris Mattmann, Ph.D. >> Senior Computer Scientist >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> Office: 171-266B, Mailstop: 171-246 >> Email: *chris.mattm...@jpl.nasa.gov >> *WWW: *http://sunset.usc.edu/~mattmann/<http://sunset.usc.edu/%7Emattmann/> >> *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Adjunct Assistant Professor, Computer Science Department >> University of Southern California, Los Angeles, CA 90089 USA >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> > > > -- > DigitalPebble Ltd > > Open Source Solutions for Text Engineering > http://www.digitalpebble.com > -- Doğacan Güney
