The board yesterday passed a resolution making HBase a TLP.

I filed an infrastructure issue to start the move:

 https://issues.apache.org/jira/browse/INFRA-2641

The primary disruption to developers will be when the subversion
repository is renamed.  We'll send out a note before we do this, then
developers can use 'svn switch' to update their repos (There is no
apache git repo that I know of... I asked just in case)

One other issue is the wiki.  I don't think it's easy to rename a
subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
have many wiki pages and could cut and paste them manually.
Alternately, we could switch to using confluence for our wiki.
Thoughts?

St.Ack
(Above shamelessly a copy of Doug's mail to the Avro list)

On Thu, Apr 22, 2010 at 10:32 AM, Stack <[EMAIL PROTECTED]> wrote:
> The primary disruption to developers will be when the subversion
> repository is renamed.  We'll send out a note before we do this, then

Technically, I don't think the repository gets renamed.  It's just a
matter of moving a directory in the tree with `svn mv'.

> developers can use 'svn switch' to update their repos (There is no
> apache git repo that I know of... I asked just in case)

I hope the read-only Git repos will get updated to track the new path
too.  I wish we could use this opportunity to switch to Git entirely.

> One other issue is the wiki.  I don't think it's easy to rename a
> subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
> have many wiki pages and could cut and paste them manually.

I'm sure we can also script that.

> Alternately, we could switch to using confluence for our wiki.

I'm against this.  Confluence = Proprietary Software.  Plus, many
people I talked to who've used it complained about its UI and wiki
syntax.  And I think it makes more sense to stay on what we already
know and use, instead of spending time migrating the contents to a
different kind of wiki.

--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com

On Thu, Apr 22, 2010 at 11:25 AM, tsuna <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 22, 2010 at 10:32 AM, Stack <[EMAIL PROTECTED]> wrote:
>> The primary disruption to developers will be when the subversion
>> repository is renamed.  We'll send out a note before we do this, then
>
> Technically, I don't think the repository gets renamed.  It's just a
> matter of moving a directory in the tree with `svn mv'.
>

Yes
>> developers can use 'svn switch' to update their repos (There is no
>> apache git repo that I know of... I asked just in case)
>
> I hope the read-only Git repos will get updated to track the new path
> too.  I wish we could use this opportunity to switch to Git entirely.
>

Who knows.  Might be a miracle in apache infrastructure between here
and our move.

>> One other issue is the wiki.  I don't think it's easy to rename a
>> subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>> have many wiki pages and could cut and paste them manually.
>
> I'm sure we can also script that.
>

Yes. Though could also be spring cleaning opportunity.

>> Alternately, we could switch to using confluence for our wiki.
>
> I'm against this.  Confluence = Proprietary Software.  Plus, many
> people I talked to who've used it complained about its UI and wiki
> syntax.  And I think it makes more sense to stay on what we already
> know and use, instead of spending time migrating the contents to a
> different kind of wiki.
>

I was for confluence because it 'cleaner' but thanks for the above, in
particular the reminder that there's work doing the convertion.

St.Ack

A lot of things in wiki should be in the site itself. Perhaps during a site
redesign....

On Apr 22, 2010 12:00 PM, "Stack" <[EMAIL PROTECTED]> wrote:

On Thu, Apr 22, 2010 at 11:25 AM, tsuna <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 22, 2010 at 10:32 ...
Yes

>> developers can use 'svn switch' to update their repos (There is no
>> apache git repo that I kn...
Who knows.  Might be a miracle in apache infrastructure between here
and our move.
>> One other issue is the wiki.  I don't think it's easy to rename a
>> subtree from a Moin Moin wi...
Yes. Though could also be spring cleaning opportunity.
>> Alternately, we could switch to using confluence for our wiki.
>
> I'm against this.  Confluence...
I was for confluence because it 'cleaner' but thanks for the above, in
particular the reminder that there's work doing the convertion.

St.Ack

+1 on moving to read-write Git.

Maybe there will be that miracle and/or we have some more input than before.

    - Andy

This is great news!

On Apr 22, 2010, at 8:32 PM, Stack wrote:

> The board yesterday passed a resolution making HBase a TLP.
>
> I filed an infrastructure issue to start the move:
>
> https://issues.apache.org/jira/browse/INFRA-2641
>
> The primary disruption to developers will be when the subversion
> repository is renamed.  We'll send out a note before we do this, then
> developers can use 'svn switch' to update their repos (There is no
> apache git repo that I know of... I asked just in case)
>
We already use the apache git.apache.org mirror for HBase. I've also seen the GitHub mirror http://github.com/apache/hbase and thought there might be some plans for migration.

> One other issue is the wiki.  I don't think it's easy to rename a
> subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
> have many wiki pages and could cut and paste them manually.
> Alternately, we could switch to using confluence for our wiki.
> Thoughts?
>
Confluence has a good integration with Jira (being both developed by Atlassian). It's functionally advanced and looks better. So +1 for that as well.

Cosmin

> St.Ack
> (Above shamelessly a copy of Doug's mail to the Avro list)

This is great news. Congrats HBase team.

(Does this mean, the packages would be refactored as o.a.hbase.* in the
trunk ? ).

--
  Karthik.
On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]> wrote:

> This is great news!
>
> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>
> > The board yesterday passed a resolution making HBase a TLP.
> >
> > I filed an infrastructure issue to start the move:
> >
> > https://issues.apache.org/jira/browse/INFRA-2641
> >
> > The primary disruption to developers will be when the subversion
> > repository is renamed.  We'll send out a note before we do this, then
> > developers can use 'svn switch' to update their repos (There is no
> > apache git repo that I know of... I asked just in case)
> >
> We already use the apache git.apache.org mirror for HBase. I've also seen
> the GitHub mirror http://github.com/apache/hbase and thought there might
> be some plans for migration.
>
> > One other issue is the wiki.  I don't think it's easy to rename a
> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
> > have many wiki pages and could cut and paste them manually.
> > Alternately, we could switch to using confluence for our wiki.
> > Thoughts?
> >
> Confluence has a good integration with Jira (being both developed by
> Atlassian). It's functionally advanced and looks better. So +1 for that as
> well.
>
> Cosmin
>
> > St.Ack
> > (Above shamelessly a copy of Doug's mail to the Avro list)
>
>

I am somewhat interested in this :-)

But it can make life difficult for our users... thoughts people?

On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
> This is great news. Congrats HBase team.
>
> (Does this mean, the packages would be refactored as o.a.hbase.* in the
> trunk ? ).
>
> --
>  Karthik.
>
>
> On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]> wrote:
>
>> This is great news!
>>
>> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>>
>> > The board yesterday passed a resolution making HBase a TLP.
>> >
>> > I filed an infrastructure issue to start the move:
>> >
>> > https://issues.apache.org/jira/browse/INFRA-2641
>> >
>> > The primary disruption to developers will be when the subversion
>> > repository is renamed.  We'll send out a note before we do this, then
>> > developers can use 'svn switch' to update their repos (There is no
>> > apache git repo that I know of... I asked just in case)
>> >
>> We already use the apache git.apache.org mirror for HBase. I've also seen
>> the GitHub mirror http://github.com/apache/hbase and thought there might
>> be some plans for migration.
>>
>> > One other issue is the wiki.  I don't think it's easy to rename a
>> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>> > have many wiki pages and could cut and paste them manually.
>> > Alternately, we could switch to using confluence for our wiki.
>> > Thoughts?
>> >
>> Confluence has a good integration with Jira (being both developed by
>> Atlassian). It's functionally advanced and looks better. So +1 for that as
>> well.
>>
>> Cosmin
>>
>> > St.Ack
>> > (Above shamelessly a copy of Doug's mail to the Avro list)
>>
>>
>

Will make patching branch and trunk even harder than it already is w/
the maven repositioning but I'm +1.  o.a.h is neat and tidy compared
to o.a.h.h.

Lets do a revamp on website while we're moving stuff around.  We
should make maven site work but that the generated maven site
index.html shouldn't be our front page (unless someone knows how to
super style the maven generation).  I'd think front page should be
nice and clean that links to maven and wiki (yeah, we should move as
much as possible of wiki into xdoc).

St.Ack
On Thu, Apr 22, 2010 at 11:19 PM, Ryan Rawson <[EMAIL PROTECTED]> wrote:
> I am somewhat interested in this :-)
>
> But it can make life difficult for our users... thoughts people?
>
> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
>> This is great news. Congrats HBase team.
>>
>> (Does this mean, the packages would be refactored as o.a.hbase.* in the
>> trunk ? ).
>>
>> --
>>  Karthik.
>>
>>
>> On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]> wrote:
>>
>>> This is great news!
>>>
>>> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>>>
>>> > The board yesterday passed a resolution making HBase a TLP.
>>> >
>>> > I filed an infrastructure issue to start the move:
>>> >
>>> > https://issues.apache.org/jira/browse/INFRA-2641
>>> >
>>> > The primary disruption to developers will be when the subversion
>>> > repository is renamed.  We'll send out a note before we do this, then
>>> > developers can use 'svn switch' to update their repos (There is no
>>> > apache git repo that I know of... I asked just in case)
>>> >
>>> We already use the apache git.apache.org mirror for HBase. I've also seen
>>> the GitHub mirror http://github.com/apache/hbase and thought there might
>>> be some plans for migration.
>>>
>>> > One other issue is the wiki.  I don't think it's easy to rename a
>>> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>>> > have many wiki pages and could cut and paste them manually.
>>> > Alternately, we could switch to using confluence for our wiki.
>>> > Thoughts?
>>> >
>>> Confluence has a good integration with Jira (being both developed by
>>> Atlassian). It's functionally advanced and looks better. So +1 for that as
>>> well.
>>>
>>> Cosmin
>>>
>>> > St.Ack
>>> > (Above shamelessly a copy of Doug's mail to the Avro list)
>>>
>>>
>>
>

I've started working with a pro designer and I'll let you all know if
it goes anywhere.

On Thu, Apr 22, 2010 at 11:29 PM, Stack <[EMAIL PROTECTED]> wrote:
> Will make patching branch and trunk even harder than it already is w/
> the maven repositioning but I'm +1.  o.a.h is neat and tidy compared
> to o.a.h.h.
>
> Lets do a revamp on website while we're moving stuff around.  We
> should make maven site work but that the generated maven site
> index.html shouldn't be our front page (unless someone knows how to
> super style the maven generation).  I'd think front page should be
> nice and clean that links to maven and wiki (yeah, we should move as
> much as possible of wiki into xdoc).
>
> St.Ack
>
>
> On Thu, Apr 22, 2010 at 11:19 PM, Ryan Rawson <[EMAIL PROTECTED]> wrote:
>> I am somewhat interested in this :-)
>>
>> But it can make life difficult for our users... thoughts people?
>>
>> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
>>> This is great news. Congrats HBase team.
>>>
>>> (Does this mean, the packages would be refactored as o.a.hbase.* in the
>>> trunk ? ).
>>>
>>> --
>>>  Karthik.
>>>
>>>
>>> On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]> wrote:
>>>
>>>> This is great news!
>>>>
>>>> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>>>>
>>>> > The board yesterday passed a resolution making HBase a TLP.
>>>> >
>>>> > I filed an infrastructure issue to start the move:
>>>> >
>>>> > https://issues.apache.org/jira/browse/INFRA-2641
>>>> >
>>>> > The primary disruption to developers will be when the subversion
>>>> > repository is renamed.  We'll send out a note before we do this, then
>>>> > developers can use 'svn switch' to update their repos (There is no
>>>> > apache git repo that I know of... I asked just in case)
>>>> >
>>>> We already use the apache git.apache.org mirror for HBase. I've also seen
>>>> the GitHub mirror http://github.com/apache/hbase and thought there might
>>>> be some plans for migration.
>>>>
>>>> > One other issue is the wiki.  I don't think it's easy to rename a
>>>> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>>>> > have many wiki pages and could cut and paste them manually.
>>>> > Alternately, we could switch to using confluence for our wiki.
>>>> > Thoughts?
>>>> >
>>>> Confluence has a good integration with Jira (being both developed by
>>>> Atlassian). It's functionally advanced and looks better. So +1 for that as
>>>> well.
>>>>
>>>> Cosmin
>>>>
>>>> > St.Ack
>>>> > (Above shamelessly a copy of Doug's mail to the Avro list)
>>>>
>>>>
>>>
>>
>

Yay HBase!

I am also interested in this.

Now might also be the time to think about breaking from hadoop numbering (I think this idea has been floating around since the first version we synced).

We've already agreed to break client compatibility for 0.20.5 and it's more than a minor revision.  And I'm sure we'll have another release between 0.20.5 and 0.21.

It's also clear that this is going to be by far our most solid release to date and so might be worthy of new shiny versioning/packaging as a TLP.  Website/docs/wiki refresher to boot.

Changing the package names is way more invasive to client code but I'm always +1 on making stuff shorter.
Anyways, I'm not doing much production cluster maintenance these days so these changes would impact me way less than others.  Will welcome pushback if you guys don't want to deal with this.

JG

> -----Original Message-----
> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 22, 2010 11:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: HBase move to Apache Top Level Project
>
> I am somewhat interested in this :-)
>
> But it can make life difficult for our users... thoughts people?
>
> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
> > This is great news. Congrats HBase team.
> >
> > (Does this mean, the packages would be refactored as o.a.hbase.* in
> the
> > trunk ? ).
> >
> > --
> >  Karthik.
> >
> >
> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
> wrote:
> >
> >> This is great news!
> >>
> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
> >>
> >> > The board yesterday passed a resolution making HBase a TLP.
> >> >
> >> > I filed an infrastructure issue to start the move:
> >> >
> >> > https://issues.apache.org/jira/browse/INFRA-2641
> >> >
> >> > The primary disruption to developers will be when the subversion
> >> > repository is renamed.  We'll send out a note before we do this,
> then
> >> > developers can use 'svn switch' to update their repos (There is no
> >> > apache git repo that I know of... I asked just in case)
> >> >
> >> We already use the apache git.apache.org mirror for HBase. I've also
> seen
> >> the GitHub mirror http://github.com/apache/hbase and thought there
> might
> >> be some plans for migration.
> >>
> >> > One other issue is the wiki.  I don't think it's easy to rename a
> >> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
> >> > have many wiki pages and could cut and paste them manually.
> >> > Alternately, we could switch to using confluence for our wiki.
> >> > Thoughts?
> >> >
> >> Confluence has a good integration with Jira (being both developed by
> >> Atlassian). It's functionally advanced and looks better. So +1 for
> that as
> >> well.
> >>
> >> Cosmin
> >>
> >> > St.Ack
> >> > (Above shamelessly a copy of Doug's mail to the Avro list)
> >>
> >>
> >

+1 on all of the above. I think with becoming a TLP it is of utmost
importance to throw down a perfect start, i.e. clean code, clean
website (!), clean build process, and a clear strategy on versioning,
roadmap etc. We have all the passion and intricate knowledge to do
that. I suggest that the Bay Area devs all get together and establish
this in one fell swoop. We have put of polishing way to long IMHO and
hopefully Ryan can get something moving with the site, if not it
should be organized differently now now. I am sure one of us the
contacts to make this happen, heck I throw in a hundred bucks if that
helps. I cannot imagine getting someone doing a current design while
integrating the established content is such a big thing.

Let us show the world what a few determined "nerds" (in the positive
sense) can achieve!

Lars

On Fri, Apr 23, 2010 at 8:44 AM, Jonathan Gray <[EMAIL PROTECTED]> wrote:
> Yay HBase!
>
> I am also interested in this.
>
> Now might also be the time to think about breaking from hadoop numbering (I think this idea has been floating around since the first version we synced).
>
> We've already agreed to break client compatibility for 0.20.5 and it's more than a minor revision.  And I'm sure we'll have another release between 0.20.5 and 0.21.
>
> It's also clear that this is going to be by far our most solid release to date and so might be worthy of new shiny versioning/packaging as a TLP.  Website/docs/wiki refresher to boot.
>
> Changing the package names is way more invasive to client code but I'm always +1 on making stuff shorter.
>
>
> Anyways, I'm not doing much production cluster maintenance these days so these changes would impact me way less than others.  Will welcome pushback if you guys don't want to deal with this.
>
> JG
>
>> -----Original Message-----
>> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, April 22, 2010 11:20 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: HBase move to Apache Top Level Project
>>
>> I am somewhat interested in this :-)
>>
>> But it can make life difficult for our users... thoughts people?
>>
>> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
>> > This is great news. Congrats HBase team.
>> >
>> > (Does this mean, the packages would be refactored as o.a.hbase.* in
>> the
>> > trunk ? ).
>> >
>> > --
>> >  Karthik.
>> >
>> >
>> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
>> wrote:
>> >
>> >> This is great news!
>> >>
>> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>> >>
>> >> > The board yesterday passed a resolution making HBase a TLP.
>> >> >
>> >> > I filed an infrastructure issue to start the move:
>> >> >
>> >> > https://issues.apache.org/jira/browse/INFRA-2641
>> >> >
>> >> > The primary disruption to developers will be when the subversion
>> >> > repository is renamed.  We'll send out a note before we do this,
>> then
>> >> > developers can use 'svn switch' to update their repos (There is no
>> >> > apache git repo that I know of... I asked just in case)
>> >> >
>> >> We already use the apache git.apache.org mirror for HBase. I've also
>> seen
>> >> the GitHub mirror http://github.com/apache/hbase and thought there
>> might
>> >> be some plans for migration.
>> >>
>> >> > One other issue is the wiki.  I don't think it's easy to rename a
>> >> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>> >> > have many wiki pages and could cut and paste them manually.
>> >> > Alternately, we could switch to using confluence for our wiki.
>> >> > Thoughts?
>> >> >
>> >> Confluence has a good integration with Jira (being both developed by
>> >> Atlassian). It's functionally advanced and looks better. So +1 for
>> that as
>> >> well.
>> >>
>> >> Cosmin
>> >>
>> >> > St.Ack
>> >> > (Above shamelessly a copy of Doug's mail to the Avro list)
>> >>
>> >>
>> >
>

On Fri, Apr 23, 2010 at 12:11 AM, Lars George <[EMAIL PROTECTED]> wrote:

> +1 on all of the above. I think with becoming a TLP it is of utmost
> importance to throw down a perfect start, i.e. clean code, clean
> website (!), clean build process, and a clear strategy on versioning,
> roadmap etc. We have all the passion and intricate knowledge to do
> that. I suggest that the Bay Area devs all get together and establish
> this in one fell swoop.
+1 - I don't think we can accomplish all of the above all at once (clean
code???) but it would be nice to have a hackathon day where we force
ourselves to only do spring cleaning and roadmapping (and not talk about fun
problems).

Pretty sure we could host at the new Cloudera office in Palo Alto - we have
a lot of space, and close to caltrain.
> We have put of polishing way to long IMHO and
> hopefully Ryan can get something moving with the site, if not it
> should be organized differently now now. I am sure one of us the
> contacts to make this happen, heck I throw in a hundred bucks if that
> helps. I cannot imagine getting someone doing a current design while
> integrating the established content is such a big thing.
>
> Let us show the world what a few determined "nerds" (in the positive
> sense) can achieve!
>
> Lars
>
> On Fri, Apr 23, 2010 at 8:44 AM, Jonathan Gray <[EMAIL PROTECTED]> wrote:
> > Yay HBase!
> >
> > I am also interested in this.
> >
> > Now might also be the time to think about breaking from hadoop numbering
> (I think this idea has been floating around since the first version we
> synced).
> >
> > We've already agreed to break client compatibility for 0.20.5 and it's
> more than a minor revision.  And I'm sure we'll have another release between
> 0.20.5 and 0.21.
> >
> > It's also clear that this is going to be by far our most solid release to
> date and so might be worthy of new shiny versioning/packaging as a TLP.
>  Website/docs/wiki refresher to boot.
> >
> > Changing the package names is way more invasive to client code but I'm
> always +1 on making stuff shorter.
> >
> >
> > Anyways, I'm not doing much production cluster maintenance these days so
> these changes would impact me way less than others.  Will welcome pushback
> if you guys don't want to deal with this.
> >
> > JG
> >
> >> -----Original Message-----
> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, April 22, 2010 11:20 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: HBase move to Apache Top Level Project
> >>
> >> I am somewhat interested in this :-)
> >>
> >> But it can make life difficult for our users... thoughts people?
> >>
> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
> >> > This is great news. Congrats HBase team.
> >> >
> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in
> >> the
> >> > trunk ? ).
> >> >
> >> > --
> >> >  Karthik.
> >> >
> >> >
> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
> >> wrote:
> >> >
> >> >> This is great news!
> >> >>
> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
> >> >>
> >> >> > The board yesterday passed a resolution making HBase a TLP.
> >> >> >
> >> >> > I filed an infrastructure issue to start the move:
> >> >> >
> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
> >> >> >
> >> >> > The primary disruption to developers will be when the subversion
> >> >> > repository is renamed.  We'll send out a note before we do this,
> >> then
> >> >> > developers can use 'svn switch' to update their repos (There is no
> >> >> > apache git repo that I know of... I asked just in case)
> >> >> >
> >> >> We already use the apache git.apache.org mirror for HBase. I've also
> >> seen
> >> >> the GitHub mirror http://github.com/apache/hbase and thought there
> >> might
> >> >> be some plans for migration.
> >> >>
> >> >> > One other issue is the wiki.  I don't think it's easy to rename a
> >> >> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't

Todd Lipcon
Software Engineer, Cloudera

On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <[EMAIL PROTECTED]> wrote:
> Now might also be the time to think about breaking from hadoop numbering (I think this idea has been floating around since the first version we synced).
>
> We've already agreed to break client compatibility for 0.20.5 and it's more than a minor revision.  And I'm sure we'll have another release between 0.20.5 and 0.21.
>

So, the new version could be 0.21 but thats not 'breaking from hadoop
numbering' and it can't be 1.0.0 .... yet.  What should it be?  0.99.0
is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
systems.  0.30.0?
> It's also clear that this is going to be by far our most solid release to date and so might be worthy of new shiny versioning/packaging as a TLP.  Website/docs/wiki refresher to boot.
>
> Changing the package names is way more invasive to client code but I'm always +1 on making stuff shorter.

Might have to keep around the old stuff deprecated.

St.Ack

>
>
> Anyways, I'm not doing much production cluster maintenance these days so these changes would impact me way less than others.  Will welcome pushback if you guys don't want to deal with this.
>
> JG
>
>> -----Original Message-----
>> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, April 22, 2010 11:20 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: HBase move to Apache Top Level Project
>>
>> I am somewhat interested in this :-)
>>
>> But it can make life difficult for our users... thoughts people?
>>
>> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
>> > This is great news. Congrats HBase team.
>> >
>> > (Does this mean, the packages would be refactored as o.a.hbase.* in
>> the
>> > trunk ? ).
>> >
>> > --
>> >  Karthik.
>> >
>> >
>> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
>> wrote:
>> >
>> >> This is great news!
>> >>
>> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>> >>
>> >> > The board yesterday passed a resolution making HBase a TLP.
>> >> >
>> >> > I filed an infrastructure issue to start the move:
>> >> >
>> >> > https://issues.apache.org/jira/browse/INFRA-2641
>> >> >
>> >> > The primary disruption to developers will be when the subversion
>> >> > repository is renamed.  We'll send out a note before we do this,
>> then
>> >> > developers can use 'svn switch' to update their repos (There is no
>> >> > apache git repo that I know of... I asked just in case)
>> >> >
>> >> We already use the apache git.apache.org mirror for HBase. I've also
>> seen
>> >> the GitHub mirror http://github.com/apache/hbase and thought there
>> might
>> >> be some plans for migration.
>> >>
>> >> > One other issue is the wiki.  I don't think it's easy to rename a
>> >> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>> >> > have many wiki pages and could cut and paste them manually.
>> >> > Alternately, we could switch to using confluence for our wiki.
>> >> > Thoughts?
>> >> >
>> >> Confluence has a good integration with Jira (being both developed by
>> >> Atlassian). It's functionally advanced and looks better. So +1 for
>> that as
>> >> well.
>> >>
>> >> Cosmin
>> >>
>> >> > St.Ack
>> >> > (Above shamelessly a copy of Doug's mail to the Avro list)
>> >>
>> >>
>> >
>

Hey Todd,

I meant the package shift to o.a.h here, not cleaning up all the code itself :)

But yes, that is what I meant, get together, not doing fun stuff but
project related management and organisation.

Lars

On Fri, Apr 23, 2010 at 9:19 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 23, 2010 at 12:11 AM, Lars George <[EMAIL PROTECTED]> wrote:
>
>> +1 on all of the above. I think with becoming a TLP it is of utmost
>> importance to throw down a perfect start, i.e. clean code, clean
>> website (!), clean build process, and a clear strategy on versioning,
>> roadmap etc. We have all the passion and intricate knowledge to do
>> that. I suggest that the Bay Area devs all get together and establish
>> this in one fell swoop.
>
>
> +1 - I don't think we can accomplish all of the above all at once (clean
> code???) but it would be nice to have a hackathon day where we force
> ourselves to only do spring cleaning and roadmapping (and not talk about fun
> problems).
>
> Pretty sure we could host at the new Cloudera office in Palo Alto - we have
> a lot of space, and close to caltrain.
>
>
>> We have put of polishing way to long IMHO and
>> hopefully Ryan can get something moving with the site, if not it
>> should be organized differently now now. I am sure one of us the
>> contacts to make this happen, heck I throw in a hundred bucks if that
>> helps. I cannot imagine getting someone doing a current design while
>> integrating the established content is such a big thing.
>>
>> Let us show the world what a few determined "nerds" (in the positive
>> sense) can achieve!
>>
>> Lars
>>
>> On Fri, Apr 23, 2010 at 8:44 AM, Jonathan Gray <[EMAIL PROTECTED]> wrote:
>> > Yay HBase!
>> >
>> > I am also interested in this.
>> >
>> > Now might also be the time to think about breaking from hadoop numbering
>> (I think this idea has been floating around since the first version we
>> synced).
>> >
>> > We've already agreed to break client compatibility for 0.20.5 and it's
>> more than a minor revision.  And I'm sure we'll have another release between
>> 0.20.5 and 0.21.
>> >
>> > It's also clear that this is going to be by far our most solid release to
>> date and so might be worthy of new shiny versioning/packaging as a TLP.
>>  Website/docs/wiki refresher to boot.
>> >
>> > Changing the package names is way more invasive to client code but I'm
>> always +1 on making stuff shorter.
>> >
>> >
>> > Anyways, I'm not doing much production cluster maintenance these days so
>> these changes would impact me way less than others.  Will welcome pushback
>> if you guys don't want to deal with this.
>> >
>> > JG
>> >
>> >> -----Original Message-----
>> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
>> >> Sent: Thursday, April 22, 2010 11:20 PM
>> >> To: [EMAIL PROTECTED]
>> >> Subject: Re: HBase move to Apache Top Level Project
>> >>
>> >> I am somewhat interested in this :-)
>> >>
>> >> But it can make life difficult for our users... thoughts people?
>> >>
>> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
>> >> > This is great news. Congrats HBase team.
>> >> >
>> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in
>> >> the
>> >> > trunk ? ).
>> >> >
>> >> > --
>> >> >  Karthik.
>> >> >
>> >> >
>> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
>> >> wrote:
>> >> >
>> >> >> This is great news!
>> >> >>
>> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>> >> >>
>> >> >> > The board yesterday passed a resolution making HBase a TLP.
>> >> >> >
>> >> >> > I filed an infrastructure issue to start the move:
>> >> >> >
>> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
>> >> >> >
>> >> >> > The primary disruption to developers will be when the subversion
>> >> >> > repository is renamed.  We'll send out a note before we do this,
>> >> then
>> >> >> > developers can use 'svn switch' to update their repos (There is no
>> >> >> > apache git repo that I know of... I asked just in case)

On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:

> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <[EMAIL PROTECTED]>
> wrote:
> > Now might also be the time to think about breaking from hadoop numbering
> (I think this idea has been floating around since the first version we
> synced).
> >
> > We've already agreed to break client compatibility for 0.20.5 and it's
> more than a minor revision.  And I'm sure we'll have another release between
> 0.20.5 and 0.21.
> >
>
> So, the new version could be 0.21 but thats not 'breaking from hadoop
> numbering' and it can't be 1.0.0 .... yet.  What should it be?  0.99.0
> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
> systems.  0.30.0?
>
>
Both deb and RPM have the concept of a version epoch, so we can make 0.3.0 >
0.20 if we like.

However, it might be confusing for users nonetheless.
>
> > It's also clear that this is going to be by far our most solid release to
> date and so might be worthy of new shiny versioning/packaging as a TLP.
>  Website/docs/wiki refresher to boot.
> >
> > Changing the package names is way more invasive to client code but I'm
> always +1 on making stuff shorter.
>
> Might have to keep around the old stuff deprecated.
>
> St.Ack
>
> >
> >
> > Anyways, I'm not doing much production cluster maintenance these days so
> these changes would impact me way less than others.  Will welcome pushback
> if you guys don't want to deal with this.
> >
> > JG
> >
> >> -----Original Message-----
> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, April 22, 2010 11:20 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: HBase move to Apache Top Level Project
> >>
> >> I am somewhat interested in this :-)
> >>
> >> But it can make life difficult for our users... thoughts people?
> >>
> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
> >> > This is great news. Congrats HBase team.
> >> >
> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in
> >> the
> >> > trunk ? ).
> >> >
> >> > --
> >> >  Karthik.
> >> >
> >> >
> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
> >> wrote:
> >> >
> >> >> This is great news!
> >> >>
> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
> >> >>
> >> >> > The board yesterday passed a resolution making HBase a TLP.
> >> >> >
> >> >> > I filed an infrastructure issue to start the move:
> >> >> >
> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
> >> >> >
> >> >> > The primary disruption to developers will be when the subversion
> >> >> > repository is renamed.  We'll send out a note before we do this,
> >> then
> >> >> > developers can use 'svn switch' to update their repos (There is no
> >> >> > apache git repo that I know of... I asked just in case)
> >> >> >
> >> >> We already use the apache git.apache.org mirror for HBase. I've also
> >> seen
> >> >> the GitHub mirror http://github.com/apache/hbase and thought there
> >> might
> >> >> be some plans for migration.
> >> >>
> >> >> > One other issue is the wiki.  I don't think it's easy to rename a
> >> >> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
> >> >> > have many wiki pages and could cut and paste them manually.
> >> >> > Alternately, we could switch to using confluence for our wiki.
> >> >> > Thoughts?
> >> >> >
> >> >> Confluence has a good integration with Jira (being both developed by
> >> >> Atlassian). It's functionally advanced and looks better. So +1 for
> >> that as
> >> >> well.
> >> >>
> >> >> Cosmin
> >> >>
> >> >> > St.Ack
> >> >> > (Above shamelessly a copy of Doug's mail to the Avro list)
> >> >>
> >> >>
> >> >
> >
>

--
Todd Lipcon
Software Engineer, Cloudera

When do we want to declare a 1.0?  When we are running on HDFS-265?
When we run on a hdfs that doesnt lose data?

If the latter, then 0.20.5 is a contender.  There is a lot of
expectation out of a 1.0.

Other options are going to an alternate scheme, like "version 20" (eg:
oracle 9) but that seems not enough of a distance.

I would probably go with something like calling 0.20.5 -> 0.9

then once we are baked, 1.0 later (trunk or branch, not sure, probably trunk)

On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <[EMAIL PROTECTED]>
>> wrote:
>> > Now might also be the time to think about breaking from hadoop numbering
>> (I think this idea has been floating around since the first version we
>> synced).
>> >
>> > We've already agreed to break client compatibility for 0.20.5 and it's
>> more than a minor revision.  And I'm sure we'll have another release between
>> 0.20.5 and 0.21.
>> >
>>
>> So, the new version could be 0.21 but thats not 'breaking from hadoop
>> numbering' and it can't be 1.0.0 .... yet.  What should it be?  0.99.0
>> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
>> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
>> systems.  0.30.0?
>>
>>
> Both deb and RPM have the concept of a version epoch, so we can make 0.3.0 >
> 0.20 if we like.
>
> However, it might be confusing for users nonetheless.
>
>
>>
>> > It's also clear that this is going to be by far our most solid release to
>> date and so might be worthy of new shiny versioning/packaging as a TLP.
>>  Website/docs/wiki refresher to boot.
>> >
>> > Changing the package names is way more invasive to client code but I'm
>> always +1 on making stuff shorter.
>>
>> Might have to keep around the old stuff deprecated.
>>
>> St.Ack
>>
>> >
>> >
>> > Anyways, I'm not doing much production cluster maintenance these days so
>> these changes would impact me way less than others.  Will welcome pushback
>> if you guys don't want to deal with this.
>> >
>> > JG
>> >
>> >> -----Original Message-----
>> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
>> >> Sent: Thursday, April 22, 2010 11:20 PM
>> >> To: [EMAIL PROTECTED]
>> >> Subject: Re: HBase move to Apache Top Level Project
>> >>
>> >> I am somewhat interested in this :-)
>> >>
>> >> But it can make life difficult for our users... thoughts people?
>> >>
>> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]> wrote:
>> >> > This is great news. Congrats HBase team.
>> >> >
>> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in
>> >> the
>> >> > trunk ? ).
>> >> >
>> >> > --
>> >> >  Karthik.
>> >> >
>> >> >
>> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]>
>> >> wrote:
>> >> >
>> >> >> This is great news!
>> >> >>
>> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
>> >> >>
>> >> >> > The board yesterday passed a resolution making HBase a TLP.
>> >> >> >
>> >> >> > I filed an infrastructure issue to start the move:
>> >> >> >
>> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
>> >> >> >
>> >> >> > The primary disruption to developers will be when the subversion
>> >> >> > repository is renamed.  We'll send out a note before we do this,
>> >> then
>> >> >> > developers can use 'svn switch' to update their repos (There is no
>> >> >> > apache git repo that I know of... I asked just in case)
>> >> >> >
>> >> >> We already use the apache git.apache.org mirror for HBase. I've also
>> >> seen
>> >> >> the GitHub mirror http://github.com/apache/hbase and thought there
>> >> might
>> >> >> be some plans for migration.
>> >> >>
>> >> >> > One other issue is the wiki.  I don't think it's easy to rename a
>> >> >> > subtree from a Moin Moin wiki to a new wiki.  Fortunately we don't
>> >> >> > have many wiki pages and could cut and paste them manually.
>> >> >> > Alternately, we could switch to using confluence for our wiki.

I think it is too early to cal the next impending 0.20.5 release to be the
1.0 release.

hadoop is going to ship 0.22 by Q3 2010, which might be Hadoop 1.0 (?). It
might make sense to name the Hbase release aligned with that Hadoop 0.22 to
be HBase 1.0.

-dhruba
On Fri, Apr 23, 2010 at 12:31 AM, Ryan Rawson <[EMAIL PROTECTED]> wrote:

> When do we want to declare a 1.0?  When we are running on HDFS-265?
> When we run on a hdfs that doesnt lose data?
>
> If the latter, then 0.20.5 is a contender.  There is a lot of
> expectation out of a 1.0.
>
> Other options are going to an alternate scheme, like "version 20" (eg:
> oracle 9) but that seems not enough of a distance.
>
> I would probably go with something like calling 0.20.5 -> 0.9
>
> then once we are baked, 1.0 later (trunk or branch, not sure, probably
> trunk)
>
>
>
> On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:
> >
> >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <[EMAIL PROTECTED]>
> >> wrote:
> >> > Now might also be the time to think about breaking from hadoop
> numbering
> >> (I think this idea has been floating around since the first version we
> >> synced).
> >> >
> >> > We've already agreed to break client compatibility for 0.20.5 and it's
> >> more than a minor revision.  And I'm sure we'll have another release
> between
> >> 0.20.5 and 0.21.
> >> >
> >>
> >> So, the new version could be 0.21 but thats not 'breaking from hadoop
> >> numbering' and it can't be 1.0.0 .... yet.  What should it be?  0.99.0
> >> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
> >> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
> >> systems.  0.30.0?
> >>
> >>
> > Both deb and RPM have the concept of a version epoch, so we can make
> 0.3.0 >
> > 0.20 if we like.
> >
> > However, it might be confusing for users nonetheless.
> >
> >
> >>
> >> > It's also clear that this is going to be by far our most solid release
> to
> >> date and so might be worthy of new shiny versioning/packaging as a TLP.
> >>  Website/docs/wiki refresher to boot.
> >> >
> >> > Changing the package names is way more invasive to client code but I'm
> >> always +1 on making stuff shorter.
> >>
> >> Might have to keep around the old stuff deprecated.
> >>
> >> St.Ack
> >>
> >> >
> >> >
> >> > Anyways, I'm not doing much production cluster maintenance these days
> so
> >> these changes would impact me way less than others.  Will welcome
> pushback
> >> if you guys don't want to deal with this.
> >> >
> >> > JG
> >> >
> >> >> -----Original Message-----
> >> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> >> >> Sent: Thursday, April 22, 2010 11:20 PM
> >> >> To: [EMAIL PROTECTED]
> >> >> Subject: Re: HBase move to Apache Top Level Project
> >> >>
> >> >> I am somewhat interested in this :-)
> >> >>
> >> >> But it can make life difficult for our users... thoughts people?
> >> >>
> >> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]>
> wrote:
> >> >> > This is great news. Congrats HBase team.
> >> >> >
> >> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in
> >> >> the
> >> >> > trunk ? ).
> >> >> >
> >> >> > --
> >> >> >  Karthik.
> >> >> >
> >> >> >
> >> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <[EMAIL PROTECTED]
> >
> >> >> wrote:
> >> >> >
> >> >> >> This is great news!
> >> >> >>
> >> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
> >> >> >>
> >> >> >> > The board yesterday passed a resolution making HBase a TLP.
> >> >> >> >
> >> >> >> > I filed an infrastructure issue to start the move:
> >> >> >> >
> >> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
> >> >> >> >
> >> >> >> > The primary disruption to developers will be when the subversion
> >> >> >> > repository is renamed.  We'll send out a note before we do this,
> >> >> then
> >> >> >> > developers can use 'svn switch' to update their repos (There is

Connect to me at http://www.facebook.com/dhruba

I would vote for 0.6.0 (this would be the 6th major release on original numbering) or 0.9.0 (and as ryan suggests, once baked, cut a 1.0)
> -----Original Message-----
> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 23, 2010 12:32 AM
> To: [EMAIL PROTECTED]
> Subject: Re: HBase move to Apache Top Level Project
>
> When do we want to declare a 1.0?  When we are running on HDFS-265?
> When we run on a hdfs that doesnt lose data?
>
> If the latter, then 0.20.5 is a contender.  There is a lot of
> expectation out of a 1.0.
>
> Other options are going to an alternate scheme, like "version 20" (eg:
> oracle 9) but that seems not enough of a distance.
>
> I would probably go with something like calling 0.20.5 -> 0.9
>
> then once we are baked, 1.0 later (trunk or branch, not sure, probably
> trunk)
>
>
>
> On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <[EMAIL PROTECTED]>
> wrote:
> > On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:
> >
> >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <[EMAIL PROTECTED]>
> >> wrote:
> >> > Now might also be the time to think about breaking from hadoop
> numbering
> >> (I think this idea has been floating around since the first version
> we
> >> synced).
> >> >
> >> > We've already agreed to break client compatibility for 0.20.5 and
> it's
> >> more than a minor revision.  And I'm sure we'll have another release
> between
> >> 0.20.5 and 0.21.
> >> >
> >>
> >> So, the new version could be 0.21 but thats not 'breaking from
> hadoop
> >> numbering' and it can't be 1.0.0 .... yet.  What should it be?
>  0.99.0
> >> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
> >> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
> >> systems.  0.30.0?
> >>
> >>
> > Both deb and RPM have the concept of a version epoch, so we can make
> 0.3.0 >
> > 0.20 if we like.
> >
> > However, it might be confusing for users nonetheless.
> >
> >
> >>
> >> > It's also clear that this is going to be by far our most solid
> release to
> >> date and so might be worthy of new shiny versioning/packaging as a
> TLP.
> >>  Website/docs/wiki refresher to boot.
> >> >
> >> > Changing the package names is way more invasive to client code but
> I'm
> >> always +1 on making stuff shorter.
> >>
> >> Might have to keep around the old stuff deprecated.
> >>
> >> St.Ack
> >>
> >> >
> >> >
> >> > Anyways, I'm not doing much production cluster maintenance these
> days so
> >> these changes would impact me way less than others.  Will welcome
> pushback
> >> if you guys don't want to deal with this.
> >> >
> >> > JG
> >> >
> >> >> -----Original Message-----
> >> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> >> >> Sent: Thursday, April 22, 2010 11:20 PM
> >> >> To: [EMAIL PROTECTED]
> >> >> Subject: Re: HBase move to Apache Top Level Project
> >> >>
> >> >> I am somewhat interested in this :-)
> >> >>
> >> >> But it can make life difficult for our users... thoughts people?
> >> >>
> >> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]>
> wrote:
> >> >> > This is great news. Congrats HBase team.
> >> >> >
> >> >> > (Does this mean, the packages would be refactored as
> o.a.hbase.* in
> >> >> the
> >> >> > trunk ? ).
> >> >> >
> >> >> > --
> >> >> >  Karthik.
> >> >> >
> >> >> >
> >> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene
> <[EMAIL PROTECTED]>
> >> >> wrote:
> >> >> >
> >> >> >> This is great news!
> >> >> >>
> >> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
> >> >> >>
> >> >> >> > The board yesterday passed a resolution making HBase a TLP.
> >> >> >> >
> >> >> >> > I filed an infrastructure issue to start the move:
> >> >> >> >
> >> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
> >> >> >> >
> >> >> >> > The primary disruption to developers will be when the
> subversion
> >> >> >> > repository is renamed.  We'll send out a note before we do
> this,
> >> >> then
> >> >> >> > developers can use 'svn switch' to update their repos (There

The problem with naming after Hadoop is the one we are in now - we
cant release hbase 0.21 without a hadoop 0.21.  We are unnecessarily
tied to Hadoop's release process, when we can provide real
improvements w/o a new HDFS/hadoop release.  Also there is the sense
that each major version of hbase must run on the corresponding hadoop
version.  While that has been true to date, there are no strong
technical reasons why this must be so, and moving forward trunk should
eventually run on 0.20 and 0.21 (or whatever they end up calling it)

Breaking the link is painful but ultimately good.  But calling 0.20.5
-> 1.0 might be too early yes.

On Fri, Apr 23, 2010 at 12:36 AM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:
> I think it is too early to cal the next impending 0.20.5 release to be the
> 1.0 release.
>
> hadoop is going to ship 0.22 by Q3 2010, which might be Hadoop 1.0 (?). It
> might make sense to name the Hbase release aligned with that Hadoop 0.22 to
> be HBase 1.0.
>
> -dhruba
>
>
> On Fri, Apr 23, 2010 at 12:31 AM, Ryan Rawson <[EMAIL PROTECTED]> wrote:
>
>> When do we want to declare a 1.0?  When we are running on HDFS-265?
>> When we run on a hdfs that doesnt lose data?
>>
>> If the latter, then 0.20.5 is a contender.  There is a lot of
>> expectation out of a 1.0.
>>
>> Other options are going to an alternate scheme, like "version 20" (eg:
>> oracle 9) but that seems not enough of a distance.
>>
>> I would probably go with something like calling 0.20.5 -> 0.9
>>
>> then once we are baked, 1.0 later (trunk or branch, not sure, probably
>> trunk)
>>
>>
>>
>> On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>> > On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:
>> >
>> >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > Now might also be the time to think about breaking from hadoop
>> numbering
>> >> (I think this idea has been floating around since the first version we
>> >> synced).
>> >> >
>> >> > We've already agreed to break client compatibility for 0.20.5 and it's
>> >> more than a minor revision.  And I'm sure we'll have another release
>> between
>> >> 0.20.5 and 0.21.
>> >> >
>> >>
>> >> So, the new version could be 0.21 but thats not 'breaking from hadoop
>> >> numbering' and it can't be 1.0.0 .... yet.  What should it be?  0.99.0
>> >> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
>> >> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
>> >> systems.  0.30.0?
>> >>
>> >>
>> > Both deb and RPM have the concept of a version epoch, so we can make
>> 0.3.0 >
>> > 0.20 if we like.
>> >
>> > However, it might be confusing for users nonetheless.
>> >
>> >
>> >>
>> >> > It's also clear that this is going to be by far our most solid release
>> to
>> >> date and so might be worthy of new shiny versioning/packaging as a TLP.
>> >>  Website/docs/wiki refresher to boot.
>> >> >
>> >> > Changing the package names is way more invasive to client code but I'm
>> >> always +1 on making stuff shorter.
>> >>
>> >> Might have to keep around the old stuff deprecated.
>> >>
>> >> St.Ack
>> >>
>> >> >
>> >> >
>> >> > Anyways, I'm not doing much production cluster maintenance these days
>> so
>> >> these changes would impact me way less than others.  Will welcome
>> pushback
>> >> if you guys don't want to deal with this.
>> >> >
>> >> > JG
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
>> >> >> Sent: Thursday, April 22, 2010 11:20 PM
>> >> >> To: [EMAIL PROTECTED]
>> >> >> Subject: Re: HBase move to Apache Top Level Project
>> >> >>
>> >> >> I am somewhat interested in this :-)
>> >> >>
>> >> >> But it can make life difficult for our users... thoughts people?
>> >> >>
>> >> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]>
>> wrote:
>> >> >> > This is great news. Congrats HBase team.
>> >> >> >
>> >> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in

Agreed that 0.20.5 itself should not be 1.0.  Don't feel that strongly about successor of 0.20.5 vs current trunk becoming a 1.0 (hopefully Q3), but don't necessarily think we should commit ourselves to the timing of any hadoop releases :)

Replication and zookeeper goodness would be nice for 1.0 as well.

> -----Original Message-----
> From: Dhruba Borthakur [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 23, 2010 12:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: HBase move to Apache Top Level Project
>
> I think it is too early to cal the next impending 0.20.5 release to be
> the
> 1.0 release.
>
> hadoop is going to ship 0.22 by Q3 2010, which might be Hadoop 1.0 (?).
> It
> might make sense to name the Hbase release aligned with that Hadoop
> 0.22 to
> be HBase 1.0.
>
> -dhruba
>
>
> On Fri, Apr 23, 2010 at 12:31 AM, Ryan Rawson <[EMAIL PROTECTED]>
> wrote:
>
> > When do we want to declare a 1.0?  When we are running on HDFS-265?
> > When we run on a hdfs that doesnt lose data?
> >
> > If the latter, then 0.20.5 is a contender.  There is a lot of
> > expectation out of a 1.0.
> >
> > Other options are going to an alternate scheme, like "version 20"
> (eg:
> > oracle 9) but that seems not enough of a distance.
> >
> > I would probably go with something like calling 0.20.5 -> 0.9
> >
> > then once we are baked, 1.0 later (trunk or branch, not sure,
> probably
> > trunk)
> >
> >
> >
> > On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <[EMAIL PROTECTED]>
> wrote:
> > > On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:
> > >
> > >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray
> <[EMAIL PROTECTED]>
> > >> wrote:
> > >> > Now might also be the time to think about breaking from hadoop
> > numbering
> > >> (I think this idea has been floating around since the first
> version we
> > >> synced).
> > >> >
> > >> > We've already agreed to break client compatibility for 0.20.5
> and it's
> > >> more than a minor revision.  And I'm sure we'll have another
> release
> > between
> > >> 0.20.5 and 0.21.
> > >> >
> > >>
> > >> So, the new version could be 0.21 but thats not 'breaking from
> hadoop
> > >> numbering' and it can't be 1.0.0 .... yet.  What should it be?
> 0.99.0
> > >> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
> > >> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
> > >> systems.  0.30.0?
> > >>
> > >>
> > > Both deb and RPM have the concept of a version epoch, so we can
> make
> > 0.3.0 >
> > > 0.20 if we like.
> > >
> > > However, it might be confusing for users nonetheless.
> > >
> > >
> > >>
> > >> > It's also clear that this is going to be by far our most solid
> release
> > to
> > >> date and so might be worthy of new shiny versioning/packaging as a
> TLP.
> > >>  Website/docs/wiki refresher to boot.
> > >> >
> > >> > Changing the package names is way more invasive to client code
> but I'm
> > >> always +1 on making stuff shorter.
> > >>
> > >> Might have to keep around the old stuff deprecated.
> > >>
> > >> St.Ack
> > >>
> > >> >
> > >> >
> > >> > Anyways, I'm not doing much production cluster maintenance these
> days
> > so
> > >> these changes would impact me way less than others.  Will welcome
> > pushback
> > >> if you guys don't want to deal with this.
> > >> >
> > >> > JG
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> > >> >> Sent: Thursday, April 22, 2010 11:20 PM
> > >> >> To: [EMAIL PROTECTED]
> > >> >> Subject: Re: HBase move to Apache Top Level Project
> > >> >>
> > >> >> I am somewhat interested in this :-)
> > >> >>
> > >> >> But it can make life difficult for our users... thoughts
> people?
> > >> >>
> > >> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <[EMAIL PROTECTED]>
> > wrote:
> > >> >> > This is great news. Congrats HBase team.
> > >> >> >
> > >> >> > (Does this mean, the packages would be refactored as
> o.a.hbase.* in
> > >> >> the
> > >> >> > trunk ? ).
> > >> >> >

I like it also. It's appropriate.

   - Andy

> From: Ryan Rawson
>
> I am somewhat interested in this :-)
>
> But it can make life difficult for our users... thoughts
> people?
>
> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K wrote:
> >
> > This is great news. Congrats HBase team.
> >
> > (Does this mean, the packages would be refactored as
> > o.a.hbase.* in the trunk ? ).

Agreed, there is no tie-up with hadoop releases, but calling the 0.20.5 as a
1.0 release might be too premature!

thanks,
dhruba
On Fri, Apr 23, 2010 at 12:41 AM, Jonathan Gray <[EMAIL PROTECTED]> wrote:

> Agreed that 0.20.5 itself should not be 1.0.  Don't feel that strongly
> about successor of 0.20.5 vs current trunk becoming a 1.0 (hopefully Q3),
> but don't necessarily think we should commit ourselves to the timing of any
> hadoop releases :)
>
> Replication and zookeeper goodness would be nice for 1.0 as well.
>
> > -----Original Message-----
> > From: Dhruba Borthakur [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 23, 2010 12:37 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: HBase move to Apache Top Level Project
> >
> > I think it is too early to cal the next impending 0.20.5 release to be
> > the
> > 1.0 release.
> >
> > hadoop is going to ship 0.22 by Q3 2010, which might be Hadoop 1.0 (?).
> > It
> > might make sense to name the Hbase release aligned with that Hadoop
> > 0.22 to
> > be HBase 1.0.
> >
> > -dhruba
> >
> >
> > On Fri, Apr 23, 2010 at 12:31 AM, Ryan Rawson <[EMAIL PROTECTED]>
> > wrote:
> >
> > > When do we want to declare a 1.0?  When we are running on HDFS-265?
> > > When we run on a hdfs that doesnt lose data?
> > >
> > > If the latter, then 0.20.5 is a contender.  There is a lot of
> > > expectation out of a 1.0.
> > >
> > > Other options are going to an alternate scheme, like "version 20"
> > (eg:
> > > oracle 9) but that seems not enough of a distance.
> > >
> > > I would probably go with something like calling 0.20.5 -> 0.9
> > >
> > > then once we are baked, 1.0 later (trunk or branch, not sure,
> > probably
> > > trunk)
> > >
> > >
> > >
> > > On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <[EMAIL PROTECTED]>
> > wrote:
> > > > On Fri, Apr 23, 2010 at 12:22 AM, Stack <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray
> > <[EMAIL PROTECTED]>
> > > >> wrote:
> > > >> > Now might also be the time to think about breaking from hadoop
> > > numbering
> > > >> (I think this idea has been floating around since the first
> > version we
> > > >> synced).
> > > >> >
> > > >> > We've already agreed to break client compatibility for 0.20.5
> > and it's
> > > >> more than a minor revision.  And I'm sure we'll have another
> > release
> > > between
> > > >> 0.20.5 and 0.21.
> > > >> >
> > > >>
> > > >> So, the new version could be 0.21 but thats not 'breaking from
> > hadoop
> > > >> numbering' and it can't be 1.0.0 .... yet.  What should it be?
> > 0.99.0
> > > >> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
> > > >> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
> > > >> systems.  0.30.0?
> > > >>
> > > >>
> > > > Both deb and RPM have the concept of a version epoch, so we can
> > make
> > > 0.3.0 >
> > > > 0.20 if we like.
> > > >
> > > > However, it might be confusing for users nonetheless.
> > > >
> > > >
> > > >>
> > > >> > It's also clear that this is going to be by far our most solid
> > release
> > > to
> > > >> date and so might be worthy of new shiny versioning/packaging as a
> > TLP.
> > > >>  Website/docs/wiki refresher to boot.
> > > >> >
> > > >> > Changing the package names is way more invasive to client code
> > but I'm
> > > >> always +1 on making stuff shorter.
> > > >>
> > > >> Might have to keep around the old stuff deprecated.
> > > >>
> > > >> St.Ack
> > > >>
> > > >> >
> > > >> >
> > > >> > Anyways, I'm not doing much production cluster maintenance these
> > days
> > > so
> > > >> these changes would impact me way less than others.  Will welcome
> > > pushback
> > > >> if you guys don't want to deal with this.
> > > >> >
> > > >> > JG
> > > >> >
> > > >> >> -----Original Message-----
> > > >> >> From: Ryan Rawson [mailto:[EMAIL PROTECTED]]
> > > >> >> Sent: Thursday, April 22, 2010 11:20 PM
> > > >> >> To: [EMAIL PROTECTED]
> > > >> >> Subject: Re: HBase move to Apache Top Level Project

Connect to me at http://www.facebook.com/dhruba

Sounds good to me. So how about doing another hackathon next month? My plan for May is to be up in the area for ~8 days over the month because I'll be around the world for 5 weeks straight after.

  - Andy

> From: Todd Lipcon
[...]
> it would be nice to have a hackathon day where
> we force ourselves to only do spring cleaning and
> roadmapping (and not talk about fun
> problems).
>
> Pretty sure we could host at the new Cloudera office in
> Palo Alto - we have a lot of space, and close to
> caltrain.

Since you're asking, IMHO, it's minimally confusing to have the next minor relase be 0.20.5, the next major release be 0.21, and the release after be 1.0, with all that entails.

   - Andy

> From: Stack
> Subject: Re: HBase move to Apache Top Level Project
>
> So, the new version could be 0.21 but thats not 'breaking
> from hadoop numbering' and it can't be 1.0.0 .... yet. What
> should it be?  0.99.0 is kinda dumb.  0.3.0? (We went as
> far as 0.2.0 on old numbering system).  0.3.0 will be less
> than 0.21.0 so will mess w/ packaging systems.  0.30.0?

I would declare 1.0 after:

  - Data durability guarantees (0.20.5 post)

  - Master rewrite (0.21 post)
      - No more region state transition holes
      - No more double assignments (use ZK to assure against)
      - Distributed log splitting

  - Tighten up splits and compactions, and failure handling of same

There may be other good things to put on the roadmap to part of a 1.0, but to my mind the above are the essentials. Basically, insure that HDFS cannot lose our data. Then, insure also that we then don't go do dumb things like leave regions in some unusable state after a failed compaction or split, or double assign and clobber something, etc.

Andy

> From: Ryan Rawson
>
> When do we want to declare a 1.0?  When we are running on
> HDFS-265? When we run on a hdfs that doesnt lose data?
>
> If the latter, then 0.20.5 is a contender.  There is a
> lot of expectation out of a 1.0.

> Lets do a revamp on website while we're moving stuff around.  We
> should make maven site work but that the generated maven site
> index.html shouldn't be our front page (unless someone knows how to
> super style the maven generation).  I'd think front page should be
> nice and clean that links to maven and wiki (yeah, we should move as
> much as possible of wiki into xdoc).

I will spend some time on the Maven site then. Shouldn't be too hard
to at least get a basic site up but this being Maven....
There are also still a few more build issues to work out but that'll
be done in time for the next release. I'll just have to find the time
to finally finish the Thrift stuff.

As to the proposed spring-cleaning hackathon: I'm very very loosely
thinking about coming to the US (it'd be my first time) for the Hadoop
Summit (I know that Paul Smith was thinking along the same lines) and
while I have no idea if I'll really be able to do that it'd be cool if
you could at least consider/keep in mind the days around that (June
29th) for some kind of HBase event (perhaps the hackathon after the
next one).

Cheers,
Lars

On Fri, Apr 23, 2010 at 1:45 AM, Lars Francke <[EMAIL PROTECTED]> wrote:
> I will spend some time on the Maven site then. Shouldn't be too hard
> to at least get a basic site up but this being Maven....

Speaking of 'mvn site', it would be awesome if it didn't take ~40
minutes to run.

And for the records, the API doc in trunk can be generated by running
`mvn javadoc:javadoc' (I was looking for this the other day at the
HBase hackathon).

--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com

> Speaking of 'mvn site', it would be awesome if it didn't take ~40
> minutes to run.

The "problem" is that the site runs the tests again (intentionally).
Cobertura has the philosophy that the tests should run once
uninstrumented and once more instrumented for coverage data to be sure
that possible failures aren't caused by the instrumentation.

Ideally all those code quality things would go into a Sonar instance
but there hasn't been any progress and there has been no answer to my
help offer. But this would shorten the site building considerably.

But be assured one of us will be working on the maven site and perhaps
the Maven documentation for HBase :)

Lars

For the sake of tracking this - HBASE-2484 in place.
On Fri, Apr 23, 2010 at 12:46 AM, Andrew Purtell <[EMAIL PROTECTED]>wrote:

> I like it also. It's appropriate.
>
>   - Andy
>
> > From: Ryan Rawson
> >
> > I am somewhat interested in this :-)
> >
> > But it can make life difficult for our users... thoughts
> > people?
> >
> > On Thu, Apr 22, 2010 at 11:17 PM, Karthik K wrote:
> > >
> > > This is great news. Congrats HBase team.
> > >
> > > (Does this mean, the packages would be refactored as
> > > o.a.hbase.* in the trunk ? ).
>
>
>
>
>
>

On Fri, Apr 23, 2010 at 9:57 AM, Lars Francke <[EMAIL PROTECTED]> wrote:
>> Speaking of 'mvn site', it would be awesome if it didn't take ~40
>> minutes to run.
>
> The "problem" is that the site runs the tests again (intentionally).

Sorry, I forgot to mention I actually ran:
  $ MAVEN_OPTS=-Xmx512m mvn site -DskipTests
and it took 37m38s on my MacBook Pro the 2nd time I ran it (I ran it
twice in a row because the first time wasn't really fair as maven
spent many minutes downloading what seemed to be the entire Internet
:D).

--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com