Grokbase Groups HBase dev May 2011
FAQ
Hi devs,

I think we should release 0.90.3 pretty soon, it already has 30 fixed
bugs including 4 blockers and a good bunch of nice to have
fixes/improvements.

Since there are no other blockers we could build a RC right now but it
seems there's a few more jiras[1] that could be quickly resolved.

This is why I'm asking all devs to review the jiras that are still
opened against 0.90.3 and to either add a fix or punt.

Thank you,

J-D


1. https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC

Search Discussions

  • Ted Yu at May 3, 2011 at 9:21 pm
    Can we get HBASE-3777 into 0.90.3 ?
    On Tue, May 3, 2011 at 2:10 PM, Jean-Daniel Cryans wrote:

    Hi devs,

    I think we should release 0.90.3 pretty soon, it already has 30 fixed
    bugs including 4 blockers and a good bunch of nice to have
    fixes/improvements.

    Since there are no other blockers we could build a RC right now but it
    seems there's a few more jiras[1] that could be quickly resolved.

    This is why I'm asking all devs to review the jiras that are still
    opened against 0.90.3 and to either add a fix or punt.

    Thank you,

    J-D


    1.
    https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
  • Jean-Daniel Cryans at May 3, 2011 at 10:01 pm
    It's a pretty big change and it would need to be backported, but I
    understand your concern.

    In my ideal world, 0.92.0 would be released in not too long and this
    would be a non-issue.

    In the real world, for all I know, 0.92.0 could be released in 6
    months or more and people would be struggling with ZK connection
    errors during all that time (and we would tell them to patch their
    0.90 themselves).

    Here's what I propose:

    - Release 0.90.3 without HBASE-3777 since it already has enough going
    and it's almost ready to go out.
    - Backport HBASE-3777 and post the patch in that jira, considering
    that the 0.90 branch won't be changing a lot in the foreseeable future
    so it should apply cleanly for some time.
    - Point people to that patch and ask them to try it out on 0.90, I
    know for sure that we'll we doing it here.
    - In the mean time, the patch will get more usage in trunk as we
    prepare a 0.92 release and might find issues.
    - Finally consider patching it in for 0.90.4 if we have enough
    confidence in it (with or without some other fixes that we would have
    figured out by then).

    Does that sound good to you?

    Thx,

    J-D
    On Tue, May 3, 2011 at 2:20 PM, Ted Yu wrote:
    Can we get HBASE-3777 into 0.90.3 ?
    On Tue, May 3, 2011 at 2:10 PM, Jean-Daniel Cryans wrote:

    Hi devs,

    I think we should release 0.90.3 pretty soon, it already has 30 fixed
    bugs including 4 blockers and a good bunch of nice to have
    fixes/improvements.

    Since there are no other blockers we could build a RC right now but it
    seems there's a few more jiras[1] that could be quickly resolved.

    This is why I'm asking all devs to review the jiras that are still
    opened against 0.90.3 and to either add a fix or punt.

    Thank you,

    J-D


    1.
    https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
  • Ted Yu at May 3, 2011 at 10:26 pm
    There're two actions we need to take:
    1. Figure out the root cause for the following test failure:

    Running org.apache.hadoop.hbase.
    client.TestHCM
    Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 406.707 sec
    <<< FAILURE!

    Results :

    Tests in error:
    testManyNewConnectionsDoesnotOOME(org.apache.hadoop.hbase.client.TestHCM)
    testRegionCaching(org.apache.hadoop.hbase.client.TestHCM)

    2. Backport HBASE-3777 to 0.90

    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777 weren't
    included in 0.90.3

    My two cents.
    On Tue, May 3, 2011 at 3:01 PM, Jean-Daniel Cryans wrote:

    It's a pretty big change and it would need to be backported, but I
    understand your concern.

    In my ideal world, 0.92.0 would be released in not too long and this
    would be a non-issue.

    In the real world, for all I know, 0.92.0 could be released in 6
    months or more and people would be struggling with ZK connection
    errors during all that time (and we would tell them to patch their
    0.90 themselves).

    Here's what I propose:

    - Release 0.90.3 without HBASE-3777 since it already has enough going
    and it's almost ready to go out.
    - Backport HBASE-3777 and post the patch in that jira, considering
    that the 0.90 branch won't be changing a lot in the foreseeable future
    so it should apply cleanly for some time.
    - Point people to that patch and ask them to try it out on 0.90, I
    know for sure that we'll we doing it here.
    - In the mean time, the patch will get more usage in trunk as we
    prepare a 0.92 release and might find issues.
    - Finally consider patching it in for 0.90.4 if we have enough
    confidence in it (with or without some other fixes that we would have
    figured out by then).

    Does that sound good to you?

    Thx,

    J-D
    On Tue, May 3, 2011 at 2:20 PM, Ted Yu wrote:
    Can we get HBASE-3777 into 0.90.3 ?

    On Tue, May 3, 2011 at 2:10 PM, Jean-Daniel Cryans <jdcryans@apache.org
    wrote:
    Hi devs,

    I think we should release 0.90.3 pretty soon, it already has 30 fixed
    bugs including 4 blockers and a good bunch of nice to have
    fixes/improvements.

    Since there are no other blockers we could build a RC right now but it
    seems there's a few more jiras[1] that could be quickly resolved.

    This is why I'm asking all devs to review the jiras that are still
    opened against 0.90.3 and to either add a fix or punt.

    Thank you,

    J-D


    1.
    https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
  • Jean-Daniel Cryans at May 4, 2011 at 12:34 am

    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777 weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Ted Yu at May 4, 2011 at 1:01 am
    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the votes.
    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans wrote:

    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777 weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Gary Helmling at May 4, 2011 at 1:15 am
    I think changing the connection "identity" handling is a pretty major
    change, and I'd be uncomfortable pushing it out in a point release before
    it's had time to be adequately tested. It's not even in the 0.90 branch
    yet. If we're trying to get out a 0.90.3 release sooner than later, then it
    doesn't seem to fit the bill.

    FYI, I only see one reference to HBASE-3777 on the user list:
    http://search-hadoop.com/m/VYHN4QbRQ2

    It may be solving real problems that people are having (I hope so!), but I
    don't see any clamoring for it to prevent a 0.90.3-rc.

    --gh

    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:

    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the votes.

    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <jdcryans@apache.org
    wrote:
    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777
    weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Ted Yu at May 4, 2011 at 1:42 am
    See email thread 'zk connection leak with TableInput/OutputFormat (CDH3b4,
    0.90.1)' which ended up with
    https://issues.apache.org/jira/browse/HBASE-3792

    See also M.C. Srivas's comment in HBASE-3777:
    'We share the same goal: with this patch, we hope to be able to scale YCSB
    to 50 client machines, with 500 threads per client, and see how HBase holds
    up.'

    I still think it is a advisable to integrate HBASE-3777 considering the
    current status of TableInputFormat and TableOutputFormat
    On Tue, May 3, 2011 at 6:14 PM, Gary Helmling wrote:

    I think changing the connection "identity" handling is a pretty major
    change, and I'd be uncomfortable pushing it out in a point release before
    it's had time to be adequately tested. It's not even in the 0.90 branch
    yet. If we're trying to get out a 0.90.3 release sooner than later, then
    it
    doesn't seem to fit the bill.

    FYI, I only see one reference to HBASE-3777 on the user list:
    http://search-hadoop.com/m/VYHN4QbRQ2

    It may be solving real problems that people are having (I hope so!), but I
    don't see any clamoring for it to prevent a 0.90.3-rc.

    --gh

    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:

    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the votes.

    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <jdcryans@apache.org
    wrote:
    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777
    weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Andrew Purtell at May 4, 2011 at 1:49 am
    Although projects can call a user vote and consider it, project committers make such decisions. Ultimately committers are responsible for insuring the quality of the code base. If a destabilizing change goes in to a point release and users are affected, committers in effect did not do their jobs well enough.

    We had considerable trouble around 0.20.4 in this regard, though the change was a LOT bigger and more invasive -- IndexedTable.

    Personally, I'm satisfied that HBASE-3777 went into trunk.

    - Andy
    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:

    The possibility of HBASE-3777 creating bigger trouble
    than without is low, in my opinion.
    Maybe we should conduct a poll in user mailing list
    and count the votes.
  • Stack at May 4, 2011 at 4:08 am
    IMO, HBASE-3777 is a critical fix -- it even addresses a regression
    introduced in 0.90.0 -- but its too risky putting it out now in a
    release from branch, at least just yet. It was only committed a day
    or so ago (Thanks Karthick and Ted for the hard work getting it in).
    I think it needs a bit of bake-in. We should be rolling a 0.92.0RC
    pretty soon. It'll get some testing then.

    We can not risk a point release that is less stable than previous
    versions; if we err, the cost in terms of support and community trust
    is just too high.

    Meantime, any chance of a backport of hbase-3777 Ted?

    Good stuff,
    St.Ack

    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:
    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the votes.
    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans wrote:

    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777 weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Ted Yu at May 4, 2011 at 4:22 am
    After discussion below, I wonder if 0.92.0RC would come out before 0.90.4
    I hope that's the case - we're looking forward to coprocessor which wouldn't
    be in 0.90.x anyway.

    Regards
    On Tue, May 3, 2011 at 9:07 PM, Stack wrote:

    IMO, HBASE-3777 is a critical fix -- it even addresses a regression
    introduced in 0.90.0 -- but its too risky putting it out now in a
    release from branch, at least just yet. It was only committed a day
    or so ago (Thanks Karthick and Ted for the hard work getting it in).
    I think it needs a bit of bake-in. We should be rolling a 0.92.0RC
    pretty soon. It'll get some testing then.

    We can not risk a point release that is less stable than previous
    versions; if we err, the cost in terms of support and community trust
    is just too high.

    Meantime, any chance of a backport of hbase-3777 Ted?

    Good stuff,
    St.Ack

    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:
    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the votes.

    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <jdcryans@apache.org
    wrote:
    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777
    weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Stack at May 4, 2011 at 4:28 am

    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before 0.90.4
    I hope that's the case - we're looking forward to coprocessor which wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm not
    sure when 0.90.4 will see light of day. There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
  • Todd Lipcon at May 4, 2011 at 5:47 am
    Maybe we should do an 0.91 dev release tout de suite? Folks who want
    3777 and coprocessors and the other nice stuff can then help us bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before 0.90.4
    I hope that's the case - we're looking forward to coprocessor which wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
    sure when 0.90.4 will see light of day.  There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at May 4, 2011 at 3:58 pm
    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each such issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who want
    3777 and coprocessors and the other nice stuff can then help us bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm not
    sure when 0.90.4 will see light of day. There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Todd Lipcon at May 4, 2011 at 5:24 pm

    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a "dev
    release" series like 0.89. That is to say, there would be no 0.91 branch,
    just a few "snapshot style" releases with minimal pre-release testing to get
    us in shape for 92. These releases would never have point releases done on
    top (and thus not need to have changes backported to them one released).

    Consider it another name for an extended release candidate period for 0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who want
    3777 and coprocessors and the other nice stuff can then help us bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm not
    sure when 0.90.4 will see light of day. There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at May 4, 2011 at 5:31 pm
    I am looking forward to this 0.91 release.
    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a "dev
    release" series like 0.89. That is to say, there would be no 0.91 branch,
    just a few "snapshot style" releases with minimal pre-release testing to
    get
    us in shape for 92. These releases would never have point releases done on
    top (and thus not need to have changes backported to them one released).

    Consider it another name for an extended release candidate period for 0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who want
    3777 and coprocessors and the other nice stuff can then help us bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm not
    sure when 0.90.4 will see light of day. There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at May 16, 2011 at 4:26 pm
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a "dev
    release" series like 0.89. That is to say, there would be no 0.91 branch,
    just a few "snapshot style" releases with minimal pre-release testing to
    get
    us in shape for 92. These releases would never have point releases done on
    top (and thus not need to have changes backported to them one released).

    Consider it another name for an extended release candidate period for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who want
    3777 and coprocessors and the other nice stuff can then help us bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm not
    sure when 0.90.4 will see light of day. There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Stack at May 16, 2011 at 6:01 pm
    We cut cut a 0.91 now as Todd suggests but would need a release
    manager to run the release.
    St.Ack
    On Mon, May 16, 2011 at 9:26 AM, Ted Yu wrote:
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a "dev
    release" series like 0.89. That is to say, there would be no 0.91 branch,
    just a few "snapshot style" releases with minimal pre-release testing to
    get
    us in shape for 92. These releases would never have point releases done on
    top (and thus not need to have changes backported to them one released).

    Consider it another name for an extended release candidate period for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who want
    3777 and coprocessors and the other nice stuff can then help us bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
    sure when 0.90.4 will see light of day.  There's a good few blockers
    and criticals but if a few of us have a go at them, we'll knock it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Todd Lipcon at May 16, 2011 at 6:02 pm

    On Mon, May 16, 2011 at 11:00 AM, Stack wrote:

    We cut cut a 0.91 now as Todd suggests but would need a release
    manager to run the release.
    I would support such a release but unfortunatelty I don't have time to
    volunteer to be an RM :(

    -Todd

    On Mon, May 16, 2011 at 9:26 AM, Ted Yu wrote:
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each
    such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a
    "dev
    release" series like 0.89. That is to say, there would be no 0.91
    branch,
    just a few "snapshot style" releases with minimal pre-release testing
    to
    get
    us in shape for 92. These releases would never have point releases done
    on
    top (and thus not need to have changes backported to them one
    released).
    Consider it another name for an extended release candidate period for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who
    want
    3777 and coprocessors and the other nice stuff can then help us
    bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out
    before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor
    which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm
    not
    sure when 0.90.4 will see light of day. There's a good few
    blockers
    and criticals but if a few of us have a go at them, we'll knock
    it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at May 16, 2011 at 6:26 pm
    I assume release manager has to be a committer. So, although I want to help
    ...
    On Mon, May 16, 2011 at 11:00 AM, Stack wrote:

    We cut cut a 0.91 now as Todd suggests but would need a release
    manager to run the release.
    St.Ack
    On Mon, May 16, 2011 at 9:26 AM, Ted Yu wrote:
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each
    such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a
    "dev
    release" series like 0.89. That is to say, there would be no 0.91
    branch,
    just a few "snapshot style" releases with minimal pre-release testing
    to
    get
    us in shape for 92. These releases would never have point releases done
    on
    top (and thus not need to have changes backported to them one
    released).
    Consider it another name for an extended release candidate period for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon wrote:

    Maybe we should do an 0.91 dev release tout de suite? Folks who
    want
    3777 and coprocessors and the other nice stuff can then help us
    bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu wrote:
    After discussion below, I wonder if 0.92.0RC would come out
    before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor
    which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so. I'm
    not
    sure when 0.90.4 will see light of day. There's a good few
    blockers
    and criticals but if a few of us have a go at them, we'll knock
    it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Jean-Daniel Cryans at May 16, 2011 at 6:31 pm
    Run the unit tests, try it on a handful of machines, basically just
    make sure it's usable.

    J-D
    On Mon, May 16, 2011 at 11:26 AM, Ted Yu wrote:
    I assume release manager has to be a committer. So, although I want to help
    ...
    On Mon, May 16, 2011 at 11:00 AM, Stack wrote:

    We cut cut a 0.91 now as Todd suggests but would need a release
    manager to run the release.
    St.Ack
    On Mon, May 16, 2011 at 9:26 AM, Ted Yu wrote:
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each
    such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a
    "dev
    release" series like 0.89. That is to say, there would be no 0.91
    branch,
    just a few "snapshot style" releases with minimal pre-release testing
    to
    get
    us in shape for 92. These releases would never have point releases done
    on
    top (and thus not need to have changes backported to them one
    released).
    Consider it another name for an extended release candidate period for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <todd@cloudera.com>
    wrote:
    Maybe we should do an 0.91 dev release tout de suite? Folks who
    want
    3777 and coprocessors and the other nice stuff can then help us
    bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu <yuzhihong@gmail.com>
    wrote:
    After discussion below, I wonder if 0.92.0RC would come out
    before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor
    which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm
    not
    sure when 0.90.4 will see light of day.  There's a good few
    blockers
    and criticals but if a few of us have a go at them, we'll knock
    it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Gaojinchao at May 17, 2011 at 1:16 am
    I can do some test for 0.90.X if it needs.


    -----邮件原件-----
    发件人: jdcryans@gmail.com 代表 Jean-Daniel Cryans
    发送时间: 2011年5月17日 2:31
    收件人: dev@hbase.apache.org
    主题: Re: Release 0.90.3 soon?

    Run the unit tests, try it on a handful of machines, basically just
    make sure it's usable.

    J-D
    On Mon, May 16, 2011 at 11:26 AM, Ted Yu wrote:
    I assume release manager has to be a committer. So, although I want to help
    ...
    On Mon, May 16, 2011 at 11:00 AM, Stack wrote:

    We cut cut a 0.91 now as Todd suggests but would need a release
    manager to run the release.
    St.Ack
    On Mon, May 16, 2011 at 9:26 AM, Ted Yu wrote:
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each
    such
    issue
    would soon be integrated to 3 branches after 0.91 branch is created.
    Sorry, I should have been clear that I would imagine 0.91 would be a
    "dev
    release" series like 0.89. That is to say, there would be no 0.91
    branch,
    just a few "snapshot style" releases with minimal pre-release testing
    to
    get
    us in shape for 92. These releases would never have point releases done
    on
    top (and thus not need to have changes backported to them one
    released).
    Consider it another name for an extended release candidate period for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <todd@cloudera.com>
    wrote:
    Maybe we should do an 0.91 dev release tout de suite? Folks who
    want
    3777 and coprocessors and the other nice stuff can then help us
    bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu <yuzhihong@gmail.com>
    wrote:
    After discussion below, I wonder if 0.92.0RC would come out
    before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor
    which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm
    not
    sure when 0.90.4 will see light of day.  There's a good few
    blockers
    and criticals but if a few of us have a go at them, we'll knock
    it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at May 17, 2011 at 1:29 am
    We were discussing release of 0.91 off of trunk.
    On Mon, May 16, 2011 at 6:16 PM, Gaojinchao wrote:

    I can do some test for 0.90.X if it needs.


    -----邮件原件-----
    发件人: jdcryans@gmail.com 代表 Jean-Daniel Cryans
    发送时间: 2011年5月17日 2:31
    收件人: dev@hbase.apache.org
    主题: Re: Release 0.90.3 soon?

    Run the unit tests, try it on a handful of machines, basically just
    make sure it's usable.

    J-D
    On Mon, May 16, 2011 at 11:26 AM, Ted Yu wrote:
    I assume release manager has to be a committer. So, although I want to help
    ...
    On Mon, May 16, 2011 at 11:00 AM, Stack wrote:

    We cut cut a 0.91 now as Todd suggests but would need a release
    manager to run the release.
    St.Ack
    On Mon, May 16, 2011 at 9:26 AM, Ted Yu wrote:
    Barney Frank's request for help brought me back to this discussion.
    When would 0.91 release come ?
    On Wed, May 4, 2011 at 10:31 AM, Ted Yu wrote:

    I am looking forward to this 0.91 release.

    On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon wrote:
    On Wed, May 4, 2011 at 8:57 AM, Ted Yu wrote:

    When would 0.91 branch be created ?
    We should reduce the number of open critical bugs for 0.90 - each
    such
    issue
    would soon be integrated to 3 branches after 0.91 branch is
    created.
    Sorry, I should have been clear that I would imagine 0.91 would be a
    "dev
    release" series like 0.89. That is to say, there would be no 0.91
    branch,
    just a few "snapshot style" releases with minimal pre-release
    testing
    to
    get
    us in shape for 92. These releases would never have point releases
    done
    on
    top (and thus not need to have changes backported to them one
    released).
    Consider it another name for an extended release candidate period
    for
    0.92.

    -Todd

    On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <todd@cloudera.com>
    wrote:
    Maybe we should do an 0.91 dev release tout de suite? Folks who
    want
    3777 and coprocessors and the other nice stuff can then help us
    bake
    towards 92 ?

    Todd
    On Tuesday, May 3, 2011, Stack wrote:
    On Tue, May 3, 2011 at 9:21 PM, Ted Yu <yuzhihong@gmail.com>
    wrote:
    After discussion below, I wonder if 0.92.0RC would come out
    before
    0.90.4
    I hope that's the case - we're looking forward to coprocessor
    which
    wouldn't
    be in 0.90.x anyway.
    Plan is to put up a 0.92.0 'soon', in the next week or so.
    I'm
    not
    sure when 0.90.4 will see light of day. There's a good few
    blockers
    and criticals but if a few of us have a go at them, we'll
    knock
    it
    out
    tout de suite (This is what I'm working on at mo).

    Good stuff,
    St.Ack
    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Stack at May 16, 2011 at 6:33 pm

    On Mon, May 16, 2011 at 11:26 AM, Ted Yu wrote:
    I assume release manager has to be a committer. So, although I want to help
    ...
    Yes, or at least needs a committer to ride shotgun to do the posting
    of the release and the few tagging commits needed.
    St.Ack
  • Dave Latham at May 4, 2011 at 4:11 pm
    I was one of those bitten by the connection identity changes in 0.90 and
    TableOutputFormat issues. I was very glad to see HBASE-3777 addressed, and
    many thanks to those who did the work to sort it out. I'd love to have it
    soon, but I have to agree that it's a pretty fundamental change and seems
    high risk to put into a point release.

    I knew there were some big changes moving from 0.20 to 0.90, so I did some
    rigorous testing on our cluster (still haven't rolled out 0.90 yet) and
    ended up making some non-trivial changes to our HBase usage and automated
    tests to accomodate the the connection identity issues in 0.90. I wouldn't
    expect that level of change in a point release, and don't put point releases
    through as much testing.

    I think it's worth putting more effort into getting 0.92 out the door as
    soon as is reasonable to get this change and others out. Keep the point
    releases as risk free as possible. Users should have a high degree of
    confidence that they are strictly improvements, and if their system works on
    one point release, it should work on the next without modifications.

    Dave
    On Tue, May 3, 2011 at 9:07 PM, Stack wrote:

    IMO, HBASE-3777 is a critical fix -- it even addresses a regression
    introduced in 0.90.0 -- but its too risky putting it out now in a
    release from branch, at least just yet. It was only committed a day
    or so ago (Thanks Karthick and Ted for the hard work getting it in).
    I think it needs a bit of bake-in. We should be rolling a 0.92.0RC
    pretty soon. It'll get some testing then.

    We can not risk a point release that is less stable than previous
    versions; if we err, the cost in terms of support and community trust
    is just too high.

    Meantime, any chance of a backport of hbase-3777 Ted?

    Good stuff,
    St.Ack

    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:
    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the votes.

    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <jdcryans@apache.org
    wrote:
    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777
    weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D
  • Todd Lipcon at May 4, 2011 at 5:22 pm

    On Wed, May 4, 2011 at 9:10 AM, Dave Latham wrote:
    I think it's worth putting more effort into getting 0.92 out the door as
    soon as is reasonable to get this change and others out. Keep the point
    releases as risk free as possible. Users should have a high degree of
    confidence that they are strictly improvements, and if their system works
    on
    one point release, it should work on the next without modifications.
    Absolutely agree. Point releases should change internal implementations, not
    interfaces (except for occasionally adding new additional ones).
    Implementation changes should be as small/risk free as possible.

    -Todd

    On Tue, May 3, 2011 at 9:07 PM, Stack wrote:

    IMO, HBASE-3777 is a critical fix -- it even addresses a regression
    introduced in 0.90.0 -- but its too risky putting it out now in a
    release from branch, at least just yet. It was only committed a day
    or so ago (Thanks Karthick and Ted for the hard work getting it in).
    I think it needs a bit of bake-in. We should be rolling a 0.92.0RC
    pretty soon. It'll get some testing then.

    We can not risk a point release that is less stable than previous
    versions; if we err, the cost in terms of support and community trust
    is just too high.

    Meantime, any chance of a backport of hbase-3777 Ted?

    Good stuff,
    St.Ack

    On Tue, May 3, 2011 at 6:00 PM, Ted Yu wrote:
    The possibility of HBASE-3777 creating bigger trouble than without is low,
    in my opinion.
    Maybe we should conduct a poll in user mailing list and count the
    votes.
    On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <
    jdcryans@apache.org
    wrote:
    Actually these two actions are related.
    I can imagine the disappointment among hbase users if HBASE-3777
    weren't
    included in 0.90.3
    I can also imagine the disappointment if we release a 0.90.3 that
    contains more bugs than it fixes, it goes both ways. Moreover,
    HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
    don't see how even if someone paid attention to the jira they would
    expect to see it in 0.90.3

    I'd like to state that I'm not trying to discredit the work that was
    done in that Jira, it was a perfect example of open source
    collaboration, but I'm rather trying to point out that it's a big
    change and that the bigger the change the better the chances are that
    there will be bugs lurking in it. You could easily list big patches
    that were committed to point releases in the past and I would agree
    with you that this is something we've done, but I can also recall a
    number of those changes that introduced more bugs and even made some
    releases unusable (like 0.20.4). Let's try to learn from our errors.

    Finally, even if it's not in 0.90.3, the fact that a backport be made
    available means that people can patch it in themselves or that other
    distros can decide to include it (like in the next CDH3 update). And
    finally we could do a 0.90.4 with it.

    J-D


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Zhoushuaifeng at May 4, 2011 at 1:31 am
    Can we get hbase-3821 into 0.90.3?
    It's a major bug, and a few change can fix it.

    Zhou Shuaifeng(Frank)
  • Stack at May 4, 2011 at 3:47 am

    On Tue, May 3, 2011 at 6:31 PM, Zhoushuaifeng wrote:
    Can we get hbase-3821 into 0.90.3?
    It's a major bug, and a few change can fix it.

    Zhou Shuaifeng(Frank)
    Committed.
    St.Ack

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieshbase, hadoop
postedMay 3, '11 at 9:10p
activeMay 17, '11 at 1:29a
posts28
users9
websitehbase.apache.org

People

Translate

site design / logo © 2022 Grokbase