You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by John W Vines <jo...@ugov.gov> on 2011/10/27 19:38:52 UTC

Branching

There has been some discussion about branching 1.4. There have been some rounds of testing done against a few iterations and we're trying to wind it down so we can be prepared for release. Unofficially we've been operating under a semi-feature freeze to avoid larger disruptions to the testing. For the sake of openness though, we seriously need to formally declare a feature freeze. I feel the best way to do this is to branch 1.4, this way 1.5 feature development can continue while we root out large scale testing bugs in the 1.4 branch.

Mentors- How long is an appropriate time to wait between announcing and carrying forward with branching? Should we put it up to vote or is simply no one objecting to branching within the timeframe sufficient?

Everyone- I think we've done a fairly good job labeling tickets as to whether they're 1.4 or 1.5. There are still some tickets which are marked 1.4, I think, which could/should be pushed on to 1.5 instead of holding back 1.4. In case of this, please open up discussions on the tickets so we can come to a decision on a case by case basis. There are a few items of discussion, particularly https://issues.apache.org/jira/browse/ACCUMULO-74 and https://issues.apache.org/jira/browse/ACCUMULO-19 which both involve packaging of Accumulo. I feel the best way to deal with these tickets in 1.4 is as follows-

If the packaging for them is done before we do the final update for 1.4 (which we will determine after sufficient testing of the frozen product) and they do not interfere with standard operating procedure, I think we should include them in 1.4 as the impact of these pom changes is very small but the impact could be large. However, I don't think we should be left waiting for these changes if they are the only things left.


Please discuss!

John

Re: Branching - UPDATE YOUR FORMATTER

Posted by John W Vines <jo...@ugov.gov>.
Trunk has been updated to 1.5. Due to our renaming system, blank lines are added to the end of files without blank lines at the end. To reduce difficulty in the future, we will alter our style to this. Please update your codestyle.xml file as I have made changes to it in both trunk and the new 1.4 branch. I will not be touching all of the 1.4 files simply because it's a very small change. But they will probably be touched once the versioning is touched on 1.4 for RCs.

John

----- Original Message -----
| From: "John W Vines" <jo...@ugov.gov>
| To: accumulo-dev@incubator.apache.org
| Sent: Monday, November 14, 2011 4:14:05 PM
| Subject: Re: Branching
| I have branched 1.4. I will be updating the trunk to reflect the 1.5
| nature of it and testing will be started shortly for the new branch
| for potential release. We need to work on the documentation though.
| 
| John

Re: Branching

Posted by John W Vines <jo...@ugov.gov>.
I have branched 1.4. I will be updating the trunk to reflect the 1.5 nature of it and testing will be started shortly for the new branch for potential release. We need to work on the documentation though.

John

Re: Branching

Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
On Oct 27, 2011, at 10:38 AM, John W Vines wrote:

> There has been some discussion about branching 1.4. There have been some rounds of testing done against a few iterations and we're trying to wind it down so we can be prepared for release. Unofficially we've been operating under a semi-feature freeze to avoid larger disruptions to the testing. For the sake of openness though, we seriously need to formally declare a feature freeze. I feel the best way to do this is to branch 1.4, this way 1.5 feature development can continue while we root out large scale testing bugs in the 1.4 branch.
> 
> Mentors- How long is an appropriate time to wait between announcing and carrying forward with branching? Should we put it up to vote or is simply no one objecting to branching within the timeframe sufficient?

Up to you guys so long as this is what the community decides on the process and, ideally, it's documented.


Regards,
Alan



Re: Branching

Posted by Jesse Yates <je...@gmail.com>.
I'm fine with whatever the current system is - it seems to be working fine.

It would just be nice if there was some documentation up on the website (or
whatever the ultimate source of truth is going to be) as to what the
process is and what the numbering means.

-- Jesse
-------------------
Jesse Yates
240-888-2200
@jesse_yates



On Tue, Nov 1, 2011 at 7:43 AM, John W Vines <jo...@ugov.gov> wrote:

> The way we've been working in 1.x being major releases with minor releases
> (1.X.Y) for major bug fixes (occasionally rolling in minor improvements
> with said bug fixes). We've been running a ~6 month dev cycle per release
> which is flexible as features come.
>
> Personally, I think this method has worked well for us and I see no reason
> to mess with it.
>
>
> John
>
> ----- Original Message -----
> | From: "Jesse Yates" <je...@gmail.com>
> | To: accumulo-dev@incubator.apache.org
> | Sent: Monday, October 31, 2011 11:48:27 PM
> | Subject: Re: Branching
> | I'm okay with branching the current trunk into 1.4.
> |
> | Here is the link to the current issues for
> | 1.4<
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+ACCUMULO+AND+fixVersion+%3D+%221.4.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide
> >
> |
> | My only concern is how the numbering for releases works. Is it that
> | odd is
> | dev and even is public release? Or are all 1.X considered public
> | releases
> | and then 1.X.Y is the minor dev release? We probably should establish
> | our
> | plans on this so we have a community standard for doing the versions
> | (though we can always change it later.
> |
> | --Jesse Yates
> | -------------------
> | Jesse Yates
> | 240-888-2200
> | @jesse_yates
> |
> | On Thu, Oct 27, 2011 at 10:38 AM, John W Vines
> | <jo...@ugov.gov>wrote:
> |
> | > There has been some discussion about branching 1.4. There have been
> | > some
> | > rounds of testing done against a few iterations and we're trying to
> | > wind it
> | > down so we can be prepared for release. Unofficially we've been
> | > operating
> | > under a semi-feature freeze to avoid larger disruptions to the
> | > testing. For
> | > the sake of openness though, we seriously need to formally declare a
> | > feature freeze. I feel the best way to do this is to branch 1.4,
> | > this way
> | > 1.5 feature development can continue while we root out large scale
> | > testing
> | > bugs in the 1.4 branch.
> | >
> | > Mentors- How long is an appropriate time to wait between announcing
> | > and
> | > carrying forward with branching? Should we put it up to vote or is
> | > simply
> | > no one objecting to branching within the timeframe sufficient?
> | >
> | > Everyone- I think we've done a fairly good job labeling tickets as
> | > to
> | > whether they're 1.4 or 1.5. There are still some tickets which are
> | > marked
> | > 1.4, I think, which could/should be pushed on to 1.5 instead of
> | > holding
> | > back 1.4. In case of this, please open up discussions on the tickets
> | > so we
> | > can come to a decision on a case by case basis. There are a few
> | > items of
> | > discussion, particularly
> | > https://issues.apache.org/jira/browse/ACCUMULO-74and
> | > https://issues.apache.org/jira/browse/ACCUMULO-19 which both involve
> | > packaging of Accumulo. I feel the best way to deal with these
> | > tickets in
> | > 1.4 is as follows-
> | >
> | > If the packaging for them is done before we do the final update for
> | > 1.4
> | > (which we will determine after sufficient testing of the frozen
> | > product)
> | > and they do not interfere with standard operating procedure, I think
> | > we
> | > should include them in 1.4 as the impact of these pom changes is
> | > very small
> | > but the impact could be large. However, I don't think we should be
> | > left
> | > waiting for these changes if they are the only things left.
> | >
> | >
> | > Please discuss!
> | >
> | > John
> | >
>

Re: Branching

Posted by John W Vines <jo...@ugov.gov>.
The way we've been working in 1.x being major releases with minor releases (1.X.Y) for major bug fixes (occasionally rolling in minor improvements with said bug fixes). We've been running a ~6 month dev cycle per release which is flexible as features come.

Personally, I think this method has worked well for us and I see no reason to mess with it.


John

----- Original Message -----
| From: "Jesse Yates" <je...@gmail.com>
| To: accumulo-dev@incubator.apache.org
| Sent: Monday, October 31, 2011 11:48:27 PM
| Subject: Re: Branching
| I'm okay with branching the current trunk into 1.4.
| 
| Here is the link to the current issues for
| 1.4<https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+ACCUMULO+AND+fixVersion+%3D+%221.4.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide>
| 
| My only concern is how the numbering for releases works. Is it that
| odd is
| dev and even is public release? Or are all 1.X considered public
| releases
| and then 1.X.Y is the minor dev release? We probably should establish
| our
| plans on this so we have a community standard for doing the versions
| (though we can always change it later.
| 
| --Jesse Yates
| -------------------
| Jesse Yates
| 240-888-2200
| @jesse_yates
| 
| On Thu, Oct 27, 2011 at 10:38 AM, John W Vines
| <jo...@ugov.gov>wrote:
| 
| > There has been some discussion about branching 1.4. There have been
| > some
| > rounds of testing done against a few iterations and we're trying to
| > wind it
| > down so we can be prepared for release. Unofficially we've been
| > operating
| > under a semi-feature freeze to avoid larger disruptions to the
| > testing. For
| > the sake of openness though, we seriously need to formally declare a
| > feature freeze. I feel the best way to do this is to branch 1.4,
| > this way
| > 1.5 feature development can continue while we root out large scale
| > testing
| > bugs in the 1.4 branch.
| >
| > Mentors- How long is an appropriate time to wait between announcing
| > and
| > carrying forward with branching? Should we put it up to vote or is
| > simply
| > no one objecting to branching within the timeframe sufficient?
| >
| > Everyone- I think we've done a fairly good job labeling tickets as
| > to
| > whether they're 1.4 or 1.5. There are still some tickets which are
| > marked
| > 1.4, I think, which could/should be pushed on to 1.5 instead of
| > holding
| > back 1.4. In case of this, please open up discussions on the tickets
| > so we
| > can come to a decision on a case by case basis. There are a few
| > items of
| > discussion, particularly
| > https://issues.apache.org/jira/browse/ACCUMULO-74and
| > https://issues.apache.org/jira/browse/ACCUMULO-19 which both involve
| > packaging of Accumulo. I feel the best way to deal with these
| > tickets in
| > 1.4 is as follows-
| >
| > If the packaging for them is done before we do the final update for
| > 1.4
| > (which we will determine after sufficient testing of the frozen
| > product)
| > and they do not interfere with standard operating procedure, I think
| > we
| > should include them in 1.4 as the impact of these pom changes is
| > very small
| > but the impact could be large. However, I don't think we should be
| > left
| > waiting for these changes if they are the only things left.
| >
| >
| > Please discuss!
| >
| > John
| >

Re: Branching

Posted by Jesse Yates <je...@gmail.com>.
I'm okay with branching the current trunk into 1.4.

Here is the link to the current issues for
1.4<https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+ACCUMULO+AND+fixVersion+%3D+%221.4.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide>

My only concern is how the numbering for releases works. Is it that odd is
dev and even is public release? Or are all 1.X considered public releases
and then 1.X.Y is the minor dev release? We probably should establish our
plans on this so we have a community standard for doing the versions
(though we can always change it later.

--Jesse Yates
-------------------
Jesse Yates
240-888-2200
@jesse_yates

On Thu, Oct 27, 2011 at 10:38 AM, John W Vines <jo...@ugov.gov>wrote:

> There has been some discussion about branching 1.4. There have been some
> rounds of testing done against a few iterations and we're trying to wind it
> down so we can be prepared for release. Unofficially we've been operating
> under a semi-feature freeze to avoid larger disruptions to the testing. For
> the sake of openness though, we seriously need to formally declare a
> feature freeze. I feel the best way to do this is to branch 1.4, this way
> 1.5 feature development can continue while we root out large scale testing
> bugs in the 1.4 branch.
>
> Mentors- How long is an appropriate time to wait between announcing and
> carrying forward with branching? Should we put it up to vote or is simply
> no one objecting to branching within the timeframe sufficient?
>
> Everyone- I think we've done a fairly good job labeling tickets as to
> whether they're 1.4 or 1.5. There are still some tickets which are marked
> 1.4, I think, which could/should be pushed on to 1.5 instead of holding
> back 1.4. In case of this, please open up discussions on the tickets so we
> can come to a decision on a case by case basis. There are a few items of
> discussion, particularly https://issues.apache.org/jira/browse/ACCUMULO-74and
> https://issues.apache.org/jira/browse/ACCUMULO-19 which both involve
> packaging of Accumulo. I feel the best way to deal with these tickets in
> 1.4 is as follows-
>
> If the packaging for them is done before we do the final update for 1.4
> (which we will determine after sufficient testing of the frozen product)
> and they do not interfere with standard operating procedure, I think we
> should include them in 1.4 as the impact of these pom changes is very small
> but the impact could be large. However, I don't think we should be left
> waiting for these changes if they are the only things left.
>
>
> Please discuss!
>
> John
>