All, Its taking a little longer than hoped. Thanks for being patient with commits. Hopefully done shortly - will let you know when we have made the switch.
------------------- Jesse Yates @jesse_yates jyates.github.com On Wed, May 23, 2012 at 11:27 PM, Jesse Yates <jesse.k.ya...@gmail.com>wrote: > Hopefully, all the committers are tuckered out from hbasecon and the > hackathon this week (great events - thanks to everyone who organized and > made it out) as I'd like to ask to for a virtual lock on the repo until *Noon > PST Tomorrow (5/24)* so Stack and I can get the modularization committed. > That means, please no commits until then noon. > > After we do the commit, any outstanding patches will need to be rebased > onto the new trunk (see earlier emails in this thread for more details on > how this works). > > Thanks for your help in this effort. > > thanks, > Jesse > > ps. look forward to our third module soon after the switch - hbase-common! > > ------------------- > Jesse Yates > @jesse_yates > jyates.github.com > > > On Wed, May 9, 2012 at 3:22 PM, Jesse Yates <jesse.k.ya...@gmail.com>wrote: > >> Created >> * HBASE-5976 to discuss the name of the initial package >> * HBASE-5977 to discuss future naming/usage of packages >> >> Go nuts. >> >> >> ------------------- >> Jesse Yates >> @jesse_yates >> jyates.github.com >> >> >> On Wed, May 9, 2012 at 2:18 PM, Elliott Clark <ecl...@stumbleupon.com>wrote: >> >>> Starting with hbase-core seems to make sense. If we started with >>> hbase-server there would be a while until all of the client and other >>> packages were split up where org.apache.hadoop.hbase.client was in the >>> hadoop-server jar. >>> >>> On Wed, May 9, 2012 at 1:34 PM, Matt Corgan <mcor...@hotpads.com> wrote: >>> >>> > Sorry about that - my intention was not to decide all future module >>> names, >>> > just to avoid having both core and common and to illustrate how we were >>> > heading that direction. >>> > >>> > >>> > On Wed, May 9, 2012 at 1:27 PM, Jesse Yates <jesse.k.ya...@gmail.com> >>> > wrote: >>> > >>> > > I was worried this discussion around naming might happen. Should I >>> open a >>> > > sub-jira on 4336 for how to name the modules, what future modules >>> should >>> > > be, etc.? >>> > > >>> > > -Jesse >>> > > ------------------- >>> > > Jesse Yates >>> > > @jesse_yates >>> > > jyates.github.com >>> > > >>> > > >>> > > On Wed, May 9, 2012 at 12:06 PM, Andrew Purtell <apurt...@apache.org >>> > >>> > > wrote: >>> > > >>> > > > On Wed, May 9, 2012 at 12:01 PM, Stack <st...@duboce.net> wrote: >>> > > > > On Wed, May 9, 2012 at 11:18 AM, Matt Corgan < >>> mcor...@hotpads.com> >>> > > > wrote: >>> > > > >> I'd suggest calling this first module hbase-server since the >>> > majority >>> > > of >>> > > > >> the classes are related to the master and regionservers. Then >>> we >>> > can >>> > > > pull >>> > > > >> out the fundamental classes (KeyValue, Bytes, etc) into a small >>> > module >>> > > > >> called hbase-core. After that, we can create an hbase-client >>> module >>> > > > that >>> > > > >> only depends on hbase-core (so few or no dependencies). My main >>> > point >>> > > > >> being that we'll want to reserve the name hbase-core for the >>> actual >>> > > core >>> > > > >> classes and not throw everything in there. >>> > > > >> >>> > > > > >>> > > > > We don't want hbase-common and then hbase-core for sure. >>> > > > > >>> > > > > The first module rightly should be called hbase-bucket since its >>> just >>> > > > > a holding module while we do our sort-through. Can we figure a >>> name >>> > > > > that better conveys the module as so? hbase-hbase? >>> hbase-bucket? >>> > > > > hbase-99%? hbase-pick-u-part? hbase-residuum? >>> > > > >>> > > > hbase-server is as reasonable as any, right? >>> > > > >>> > > > Best regards, >>> > > > >>> > > > - Andy >>> > > > >>> > > > Problems worthy of attack prove their worth by hitting back. - Piet >>> > > > Hein (via Tom White) >>> > > > >>> > > >>> > >>> >> >> >
