Hey Julien, >> I wouldn't favor a Nutch contrib going forward. Contribs lead to >> umbrella-projects which Apache is moving away from b/c it typically creates >> different committer lists (those who can commit to contrib and those with >> commit privs to the full source code base, etc.), different lifecycles and >> ultimately incubates/grows mini-projects within larger ones. > > I meant putting the migration code and 1.x Nutch jars in the contrib directory > of the trunk - that shouldn't require a different committers list or should > it?
Not outright, but it's the principle that matters. Contribs typically _imply_ what I suggested, but nothing really _enforces_ it, thought it would be confusing to have contribs just as a dir name. I favor getting rid of it. > >> >> If someone needs Nutch 1.x jars they can grab them from the Apache distros >> or we can publish them to Maven central. As for conversion and removal of >> src/java, I'm not sure I get that? Why should we remove src/java? Merge >> means "adapt existing" rather than "replace". > > I was talking about removing deprecated Nutch objects (old Writables which we > needed for storing things in Hadoop MapFiles) from the src after the merge > once they are not used by Nutch2.0. +1 > > The point made by Dogacan was that they would be needed if we want to provide > conversion tools so that people could convert their old crawldbs and segments > into our shiny new Gora-based architecture. Gotcha, comments below. >> >> Nah, IMHO I think it's OK to muck around in the branch, so long as when the >> branch gets merged (incrementally rather than wholesale), we can review >> those. So, the way it would work is this: >> >> A. branch cleaned up, SVN commits, etc., stable working >> B. at some point, branch ready to be merged (assumption: branch devel stops) >> C. define branch merge into 3-5 patches >> D. foreach patch in C: >> create JIRA issue for patch >> call for review of patch >> if no objections, then commit in 24-48 hours >> >> E. trunk now ready for 2.0 development >> F. schedule current open issues for 2.0, grab any low hanging fruit (1-2 >> days) >> G. all other issues pushed out to 2.1 >> H. release 2.0 >> > > Andrzej and myself are in the process of porting the last missing tests in > NutchBase and debugging Gora along the way. There is just a handful of plugins > which have not been ported and I should have finished that pretty quickly. > Hopefully we'll get to (A) soonish and can then follow the plan above. +1 > > However we still need to address the issue raise by Dogacan i.e shall we > provide tools to convert from 1.x structures to 2.0 and if so how shall we > organise it. Again - some things have been removed fom NutchBase for the sake > of clarity but since they are in the trunk they are not lost and we can decide > what to do with them later. Maybe we can provide a couple of encapsulated upgradetools that contain internal versions of the necessary Nutch1.x classes that live inside of the Tool class. This way they are hidden and not cluttering the sources, but the point is still accomplished. Thoughts? Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
