You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafodion.apache.org by Steve Varnau <st...@esgyn.com> on 2015/10/07 19:14:51 UTC
Start another branch for HBase 1.0 support
Trafodion Developers,
We are working toward our first release (1.2) under Incubator project.
Meanwhile, folks are starting work on supporting HBase 1.x for future
release. So I’d like to propose we start another branch to support both
lines of work.
If we do that, it does imply some extra overhead for changes that apply to
both lines of work. Each developer will have to submit change to each
branch, or someone will need to occasionally merge all the 1.2 work
forward. Given that each developer would know their change-set the best
they should be the ones to submit it to each branch.
**Given that overhead, do you agree that it is time to start another
branch?**
Strategy we’ve used in past is to put the imminent release on a side branch
(e.g., stable/1.2) that can be used to stabilize code for release and for
any post-release patches. Which would allow new feature development to
continue on master branch.
If majority of changes are still going to be aimed for 1.2 release for some
time to come, we could keep 1.2 on master branch and have a temporary
feature branch for hbase1.0, but my proposal is to go ahead to create
stable/1.2 and allow next release work to come into master branch.
**Do you agree to create stable/1.2, and open master branch for net release
features?**
Let me know what you think. I’ll work on setting up build & test automation
to support two branches.
--Steve
RE: Start another branch for HBase 1.0 support
Posted by Steve Varnau <st...@esgyn.com>.
Outstanding pull requests were created against master branch, so if/when
they merge, the committers would presumably merge them to master branch. If
the committer/author agree that the intended target is really the stable/1.2
branch, I suppose the committer could push it there just as easily.
--Steve
-----Original Message-----
From: Dave Birdsall [mailto:dave.birdsall@esgyn.com]
Sent: Wednesday, October 7, 2015 12:07 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: Start another branch for HBase 1.0 support
What would be the impact on outstanding pull requests?
-----Original Message-----
From: Hans Zeller [mailto:hans.zeller@esgyn.com]
Sent: Wednesday, October 7, 2015 12:01 PM
To: dev <de...@trafodion.incubator.apache.org>
Subject: Re: Start another branch for HBase 1.0 support
Hi,
My two cents: If developers need to submit their changes into two branches,
then I would vote to hold of another couple of weeks, as Roberta mentions.
If we can do a wholesale merge of 1.2.0 into the new hbase1.0 distro, then
splitting now would be fine.
Thanks,
Hans
On Wed, Oct 7, 2015 at 10:40 AM, Roberta Marton <ro...@esgyn.com>
wrote:
> Realistically, it will take another couple of weeks to put all the
> pieces together and release our first tarball to the test site for release
> 1.2.0.
> After we get the source released, it may be a couple of more weeks to
> get it through the Apache process.
> But, if everything thing goes like clockwork, it could be less time.
>
> Roberta
>
> -----Original Message-----
> From: Dave Birdsall [mailto:dave.birdsall@esgyn.com]
> Sent: Wednesday, October 7, 2015 10:23 AM
> To: dev@trafodion.incubator.apache.org
> Subject: RE: Start another branch for HBase 1.0 support
>
> What is the proposed timing?
>
> -----Original Message-----
> From: Steve Varnau [mailto:steve.varnau@esgyn.com]
> Sent: Wednesday, October 7, 2015 10:15 AM
> To: dev@trafodion.incubator.apache.org
> Subject: Start another branch for HBase 1.0 support
>
> Trafodion Developers,
>
>
>
> We are working toward our first release (1.2) under Incubator project.
> Meanwhile, folks are starting work on supporting HBase 1.x for future
> release. So I’d like to propose we start another branch to support
> both lines of work.
>
>
>
> If we do that, it does imply some extra overhead for changes that
> apply to both lines of work. Each developer will have to submit change
> to each branch, or someone will need to occasionally merge all the 1.2
> work forward.
> Given that each developer would know their change-set the best they
> should be the ones to submit it to each branch.
>
>
>
> **Given that overhead, do you agree that it is time to start another
> branch?**
>
>
>
> Strategy we’ve used in past is to put the imminent release on a side
> branch (e.g., stable/1.2) that can be used to stabilize code for
> release and for any post-release patches. Which would allow new
> feature development to continue on master branch.
>
>
>
> If majority of changes are still going to be aimed for 1.2 release for
> some time to come, we could keep 1.2 on master branch and have a
> temporary feature branch for hbase1.0, but my proposal is to go ahead
> to create
> stable/1.2 and allow next release work to come into master branch.
>
>
>
> **Do you agree to create stable/1.2, and open master branch for net
> release
> features?**
>
>
>
> Let me know what you think. I’ll work on setting up build & test
> automation to support two branches.
>
>
>
> --Steve
>
RE: Start another branch for HBase 1.0 support
Posted by Dave Birdsall <da...@esgyn.com>.
What would be the impact on outstanding pull requests?
-----Original Message-----
From: Hans Zeller [mailto:hans.zeller@esgyn.com]
Sent: Wednesday, October 7, 2015 12:01 PM
To: dev <de...@trafodion.incubator.apache.org>
Subject: Re: Start another branch for HBase 1.0 support
Hi,
My two cents: If developers need to submit their changes into two branches,
then I would vote to hold of another couple of weeks, as Roberta mentions.
If we can do a wholesale merge of 1.2.0 into the new hbase1.0 distro, then
splitting now would be fine.
Thanks,
Hans
On Wed, Oct 7, 2015 at 10:40 AM, Roberta Marton <ro...@esgyn.com>
wrote:
> Realistically, it will take another couple of weeks to put all the
> pieces together and release our first tarball to the test site for release
> 1.2.0.
> After we get the source released, it may be a couple of more weeks to
> get it through the Apache process.
> But, if everything thing goes like clockwork, it could be less time.
>
> Roberta
>
> -----Original Message-----
> From: Dave Birdsall [mailto:dave.birdsall@esgyn.com]
> Sent: Wednesday, October 7, 2015 10:23 AM
> To: dev@trafodion.incubator.apache.org
> Subject: RE: Start another branch for HBase 1.0 support
>
> What is the proposed timing?
>
> -----Original Message-----
> From: Steve Varnau [mailto:steve.varnau@esgyn.com]
> Sent: Wednesday, October 7, 2015 10:15 AM
> To: dev@trafodion.incubator.apache.org
> Subject: Start another branch for HBase 1.0 support
>
> Trafodion Developers,
>
>
>
> We are working toward our first release (1.2) under Incubator project.
> Meanwhile, folks are starting work on supporting HBase 1.x for future
> release. So I’d like to propose we start another branch to support
> both lines of work.
>
>
>
> If we do that, it does imply some extra overhead for changes that
> apply to both lines of work. Each developer will have to submit change
> to each branch, or someone will need to occasionally merge all the 1.2
> work forward.
> Given that each developer would know their change-set the best they
> should be the ones to submit it to each branch.
>
>
>
> **Given that overhead, do you agree that it is time to start another
> branch?**
>
>
>
> Strategy we’ve used in past is to put the imminent release on a side
> branch (e.g., stable/1.2) that can be used to stabilize code for
> release and for any post-release patches. Which would allow new
> feature development to continue on master branch.
>
>
>
> If majority of changes are still going to be aimed for 1.2 release for
> some time to come, we could keep 1.2 on master branch and have a
> temporary feature branch for hbase1.0, but my proposal is to go ahead
> to create
> stable/1.2 and allow next release work to come into master branch.
>
>
>
> **Do you agree to create stable/1.2, and open master branch for net
> release
> features?**
>
>
>
> Let me know what you think. I’ll work on setting up build & test
> automation to support two branches.
>
>
>
> --Steve
>
Re: Start another branch for HBase 1.0 support
Posted by Hans Zeller <ha...@esgyn.com>.
Hi,
My two cents: If developers need to submit their changes into two branches,
then I would vote to hold of another couple of weeks, as Roberta mentions.
If we can do a wholesale merge of 1.2.0 into the new hbase1.0 distro, then
splitting now would be fine.
Thanks,
Hans
On Wed, Oct 7, 2015 at 10:40 AM, Roberta Marton <ro...@esgyn.com>
wrote:
> Realistically, it will take another couple of weeks to put all the pieces
> together and release our first tarball to the test site for release 1.2.0.
> After we get the source released, it may be a couple of more weeks to get
> it
> through the Apache process.
> But, if everything thing goes like clockwork, it could be less time.
>
> Roberta
>
> -----Original Message-----
> From: Dave Birdsall [mailto:dave.birdsall@esgyn.com]
> Sent: Wednesday, October 7, 2015 10:23 AM
> To: dev@trafodion.incubator.apache.org
> Subject: RE: Start another branch for HBase 1.0 support
>
> What is the proposed timing?
>
> -----Original Message-----
> From: Steve Varnau [mailto:steve.varnau@esgyn.com]
> Sent: Wednesday, October 7, 2015 10:15 AM
> To: dev@trafodion.incubator.apache.org
> Subject: Start another branch for HBase 1.0 support
>
> Trafodion Developers,
>
>
>
> We are working toward our first release (1.2) under Incubator project.
> Meanwhile, folks are starting work on supporting HBase 1.x for future
> release. So I’d like to propose we start another branch to support both
> lines of work.
>
>
>
> If we do that, it does imply some extra overhead for changes that apply to
> both lines of work. Each developer will have to submit change to each
> branch, or someone will need to occasionally merge all the 1.2 work
> forward.
> Given that each developer would know their change-set the best they should
> be the ones to submit it to each branch.
>
>
>
> **Given that overhead, do you agree that it is time to start another
> branch?**
>
>
>
> Strategy we’ve used in past is to put the imminent release on a side branch
> (e.g., stable/1.2) that can be used to stabilize code for release and for
> any post-release patches. Which would allow new feature development to
> continue on master branch.
>
>
>
> If majority of changes are still going to be aimed for 1.2 release for some
> time to come, we could keep 1.2 on master branch and have a temporary
> feature branch for hbase1.0, but my proposal is to go ahead to create
> stable/1.2 and allow next release work to come into master branch.
>
>
>
> **Do you agree to create stable/1.2, and open master branch for net release
> features?**
>
>
>
> Let me know what you think. I’ll work on setting up build & test automation
> to support two branches.
>
>
>
> --Steve
>
RE: Start another branch for HBase 1.0 support
Posted by Roberta Marton <ro...@esgyn.com>.
Realistically, it will take another couple of weeks to put all the pieces
together and release our first tarball to the test site for release 1.2.0.
After we get the source released, it may be a couple of more weeks to get it
through the Apache process.
But, if everything thing goes like clockwork, it could be less time.
Roberta
-----Original Message-----
From: Dave Birdsall [mailto:dave.birdsall@esgyn.com]
Sent: Wednesday, October 7, 2015 10:23 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: Start another branch for HBase 1.0 support
What is the proposed timing?
-----Original Message-----
From: Steve Varnau [mailto:steve.varnau@esgyn.com]
Sent: Wednesday, October 7, 2015 10:15 AM
To: dev@trafodion.incubator.apache.org
Subject: Start another branch for HBase 1.0 support
Trafodion Developers,
We are working toward our first release (1.2) under Incubator project.
Meanwhile, folks are starting work on supporting HBase 1.x for future
release. So I’d like to propose we start another branch to support both
lines of work.
If we do that, it does imply some extra overhead for changes that apply to
both lines of work. Each developer will have to submit change to each
branch, or someone will need to occasionally merge all the 1.2 work forward.
Given that each developer would know their change-set the best they should
be the ones to submit it to each branch.
**Given that overhead, do you agree that it is time to start another
branch?**
Strategy we’ve used in past is to put the imminent release on a side branch
(e.g., stable/1.2) that can be used to stabilize code for release and for
any post-release patches. Which would allow new feature development to
continue on master branch.
If majority of changes are still going to be aimed for 1.2 release for some
time to come, we could keep 1.2 on master branch and have a temporary
feature branch for hbase1.0, but my proposal is to go ahead to create
stable/1.2 and allow next release work to come into master branch.
**Do you agree to create stable/1.2, and open master branch for net release
features?**
Let me know what you think. I’ll work on setting up build & test automation
to support two branches.
--Steve
RE: Start another branch for HBase 1.0 support
Posted by Steve Varnau <st...@esgyn.com>.
That is part of the question. Are we ready "now"? If we say we are ready
now, it may take a day or two to set up Jenkins build jobs, etc to fully
support both branches.
If anyone does not think "now" is the right time, I'd expect they would
state when or a criteria for when.
Another coordinated effort has to happen in future when we switch testing to
HBase 1.0 distro, but that is not required to just start new branch.
--Steve
-----Original Message-----
From: Dave Birdsall [mailto:dave.birdsall@esgyn.com]
Sent: Wednesday, October 7, 2015 10:23 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: Start another branch for HBase 1.0 support
What is the proposed timing?
-----Original Message-----
From: Steve Varnau [mailto:steve.varnau@esgyn.com]
Sent: Wednesday, October 7, 2015 10:15 AM
To: dev@trafodion.incubator.apache.org
Subject: Start another branch for HBase 1.0 support
Trafodion Developers,
We are working toward our first release (1.2) under Incubator project.
Meanwhile, folks are starting work on supporting HBase 1.x for future
release. So I’d like to propose we start another branch to support both
lines of work.
If we do that, it does imply some extra overhead for changes that apply to
both lines of work. Each developer will have to submit change to each
branch, or someone will need to occasionally merge all the 1.2 work forward.
Given that each developer would know their change-set the best they should
be the ones to submit it to each branch.
**Given that overhead, do you agree that it is time to start another
branch?**
Strategy we’ve used in past is to put the imminent release on a side branch
(e.g., stable/1.2) that can be used to stabilize code for release and for
any post-release patches. Which would allow new feature development to
continue on master branch.
If majority of changes are still going to be aimed for 1.2 release for some
time to come, we could keep 1.2 on master branch and have a temporary
feature branch for hbase1.0, but my proposal is to go ahead to create
stable/1.2 and allow next release work to come into master branch.
**Do you agree to create stable/1.2, and open master branch for net release
features?**
Let me know what you think. I’ll work on setting up build & test automation
to support two branches.
--Steve
RE: Start another branch for HBase 1.0 support
Posted by Dave Birdsall <da...@esgyn.com>.
What is the proposed timing?
-----Original Message-----
From: Steve Varnau [mailto:steve.varnau@esgyn.com]
Sent: Wednesday, October 7, 2015 10:15 AM
To: dev@trafodion.incubator.apache.org
Subject: Start another branch for HBase 1.0 support
Trafodion Developers,
We are working toward our first release (1.2) under Incubator project.
Meanwhile, folks are starting work on supporting HBase 1.x for future
release. So I’d like to propose we start another branch to support both
lines of work.
If we do that, it does imply some extra overhead for changes that apply to
both lines of work. Each developer will have to submit change to each
branch, or someone will need to occasionally merge all the 1.2 work forward.
Given that each developer would know their change-set the best they should
be the ones to submit it to each branch.
**Given that overhead, do you agree that it is time to start another
branch?**
Strategy we’ve used in past is to put the imminent release on a side branch
(e.g., stable/1.2) that can be used to stabilize code for release and for
any post-release patches. Which would allow new feature development to
continue on master branch.
If majority of changes are still going to be aimed for 1.2 release for some
time to come, we could keep 1.2 on master branch and have a temporary
feature branch for hbase1.0, but my proposal is to go ahead to create
stable/1.2 and allow next release work to come into master branch.
**Do you agree to create stable/1.2, and open master branch for net release
features?**
Let me know what you think. I’ll work on setting up build & test automation
to support two branches.
--Steve