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 (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
