You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2012/05/30 23:04:31 UTC
[DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Hi folks,
I probably should have started this discussion a few days back. We
currently have two branches in the repo 3.0.x and master, and we need
to decide what we want to base 4.0.0 on.
My personal take:
We should take 3.0.x and run with it - it has a minimum of new
features over the last CloudStack release - is comparatively stable,
was undergoing lots of testing right before the transition to the ASF
git repo. This comparatively stable base allows us to focus on just
the changes needed to get the first release out (which obviously would
also have to be committed into the master branch at the same time).
The master branch has a lot more future development [1]
My concern is that there is a non-trivial amount of work to get our
first release out including but not limited to:
* Notice and License file creation
* Getting new copyright/header information in place
* Removing deps that aren't licensed with an ASF-approved license.
If we couple that with trying to get new features in - along with the
extended QA and devel cycles - we extend the time period for the first
ACS release.
So I'd propose we adopt the following:
>From this point forward bugfixes only into the 3.0.x branch - and we
begin focusing on getting an ASF-acceptable release ready
Simultaneous push of bugfixes up to master.
New features going to master for 4.1.x (though our focus should
really be on getting an ASF-acceptable release out)
Rename the 3.0.x branch to 4.0.x to reflect reality.
Thoughts, comments, flames?
--David
[1] git log --left-right --graph --cherry-pick --oneline 3.0.x...master
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi
I agree that branching from a branch is not the way to go. But at the
same time I agree with David that we need to follow the rule:
- Release soon and release regularly
also I agree with David that next release must focus more on cleaning the
code or at least starting to clean the code
The bottom line is:
1- The community is very big and healthy so I am not worried about getting
new blood into the project
2- That leaves one thing left, that is complying the code to ASF rules and
getting releases out
That would fasten our graduation from the incubator
On Thu, May 31, 2012 at 7:35 PM, David Nalley <da...@gnsa.us> wrote:
> On Thu, May 31, 2012 at 8:15 AM, Robert Schweikert <rj...@suse.com>
> wrote:
> > On 05/31/2012 12:35 AM, Kevin Kluge wrote:
> >>
> >> The master branch hasn't diverged much from the 3.0.x branch at this
> >> point. I can't name any divergence off the top of my head. I would
> expect
> >> 3.0.x to be more stable, but if there is another reason to go forth with
> >> master then I wouldn't stop that for stability reasons.
> >>
> >>> New features going to master for 4.1.x (though our focus should really
> >>> be on
> >>> getting an ASF-acceptable release out) Rename the 3.0.x branch to 4.0.x
> >>> to
> >>> reflect reality.
> >>
> >>
> >> Renaming the branch will create confusion. The previous 3.0.x releases
> >> have already been done off of it so all the committers (and anyone else
> that
> >> has been looking at the code) are expecting this to be the 3.0.x release
> >> set. We could plausibly cut a 4.0.0 and future 4.0.x releases off the
> 3.0.x
> >> branch. That is a little odd but (IMO) less confusing than renaming the
> >> branch out from under people.
> >>
> >> We could also take a 4.0.x branch off 3.0.x or master. That leaves
> open
> >> the option of a later 3.0.x release on the 3.0.x branch. That seems the
> >> cleanest approach to me, but it would add some additional branch
> management
> >> overhead if fixes are needed in both 3.0.x and 4.0.x.
> >>
> >> I might have a slight preference to branching 4.0.x off master. Then we
> >> would establish a pattern that major releases get branched from master,
> as
> >> was done for 3.0.0 and 4.0.0. This would extend naturally into 5.0.0,
> etc.
> >> and is easy to explain to new committers.
> >
> >
> > I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of master is
> > confusing. We should always branch major release branches off master.
> This
> > does not mean we have to branch 4.0.x of HEAD in master, we can choose an
> > earlier commit in master if there is concern that HEAD has some
> > instabilities.
> >
> > My $0.02
> > Robert
>
> OK - I can see the logic in that. Soooo - do we need the 3.0.x branch
> around anymore? Or perhaps better put - do we intend to use it - even
> if we don't purge it? A couple of follow on questions - when should we
> branch master to build 4.0.x?
>
> --David
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by John Kinsella <jl...@stratosec.co>.
On Jun 2, 2012, at 3:38 PM, David Nalley wrote:
> I think the consensus thus far has been to work in master - and
> eventually branch when we get close to release (I am thinking perhaps
> the RC timeframe). Feature development can continue moving forward via
> topic branches that stay closed based on master. Though I personally
> don't want to focus on features until we get the first Apache release
> done - there's enough work there for folks to accomplish in and of
> itself.
+1
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by David Nalley <da...@gnsa.us>.
On Sat, Jun 2, 2012 at 8:09 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 06/02/2012 02:22 AM, Kevin Kluge wrote:
>>>>>
>>>>>
>>>>> Well, that's kind off a Citrix question. Is Citrix interested in
>>>>> having a public branch to work in? From a community perspective it
>>>>> woudl appear that only the master branch is of interest plus any
>>>>> feature branches that are public.
>>>>
>>>>
>>>> I don't get the Citrix question?
>>>
>>>
>>> Cirtix has released/is releasing their product from the 3.0.x branch. It
>>> is AFAIK
>>> immaterial to the community. However, if Citrix is interested in keeping
>>> the
>>> 3.0.x branch in the open on the Apache git server, the community should
>>> not
>>> remove the branch as Cirtrix is after all also a member of the community.
>>>
>>> Thus the Citrix connection and the relevance to this discussion.
>>
>>
>> Citrix could continue to do commercial releases off the 3.0.x branch even
>> if it were deleted from the Apache git repo since there are several other
>> places that would still have 3.0.x.
>>
>> I'd ask if anyone (besides Citrix) has cause to be interested in the 3.0.x
>> branch at this point. If not it seems harmless to delete it, and push
>> focus to master and a new 4.0.x branch.
>
>
> Have we come to a consensus that we will be working in two different
> branches? master and 4.0.x?
>
> I'm still voting for doing all the development in the master branch,
> developing new features in a feature branch and merge them in when they are
> ready.
>
> When we think the master branch has reached the point of a new release we
> tag that release.
>
> A automated build system can then even build packages and tarballs based on
> the tags of the master branch.
>
> I don't like working in two different branches, it makes merging in new
> stuff extra difficult imho.
>
> Wido
>
I think the consensus thus far has been to work in master - and
eventually branch when we get close to release (I am thinking perhaps
the RC timeframe). Feature development can continue moving forward via
topic branches that stay closed based on master. Though I personally
don't want to focus on features until we get the first Apache release
done - there's enough work there for folks to accomplish in and of
itself.
--David
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Wido den Hollander <wi...@widodh.nl>.
On 06/02/2012 02:22 AM, Kevin Kluge wrote:
>>>>
>>>> Well, that's kind off a Citrix question. Is Citrix interested in
>>>> having a public branch to work in? From a community perspective it
>>>> woudl appear that only the master branch is of interest plus any
>>>> feature branches that are public.
>>>
>>> I don't get the Citrix question?
>>
>> Cirtix has released/is releasing their product from the 3.0.x branch. It is AFAIK
>> immaterial to the community. However, if Citrix is interested in keeping the
>> 3.0.x branch in the open on the Apache git server, the community should not
>> remove the branch as Cirtrix is after all also a member of the community.
>>
>> Thus the Citrix connection and the relevance to this discussion.
>
> Citrix could continue to do commercial releases off the 3.0.x branch even if it were deleted from the Apache git repo since there are several other places that would still have 3.0.x.
>
> I'd ask if anyone (besides Citrix) has cause to be interested in the 3.0.x branch at this point. If not it seems harmless to delete it, and push focus to master and a new 4.0.x branch.
Have we come to a consensus that we will be working in two different
branches? master and 4.0.x?
I'm still voting for doing all the development in the master branch,
developing new features in a feature branch and merge them in when they
are ready.
When we think the master branch has reached the point of a new release
we tag that release.
A automated build system can then even build packages and tarballs based
on the tags of the master branch.
I don't like working in two different branches, it makes merging in new
stuff extra difficult imho.
Wido
>
> -kevin
RE: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Kevin Kluge <Ke...@citrix.com>.
> >>
> >> Well, that's kind off a Citrix question. Is Citrix interested in
> >> having a public branch to work in? From a community perspective it
> >> woudl appear that only the master branch is of interest plus any
> >> feature branches that are public.
> >
> > I don't get the Citrix question?
>
> Cirtix has released/is releasing their product from the 3.0.x branch. It is AFAIK
> immaterial to the community. However, if Citrix is interested in keeping the
> 3.0.x branch in the open on the Apache git server, the community should not
> remove the branch as Cirtrix is after all also a member of the community.
>
> Thus the Citrix connection and the relevance to this discussion.
Citrix could continue to do commercial releases off the 3.0.x branch even if it were deleted from the Apache git repo since there are several other places that would still have 3.0.x.
I'd ask if anyone (besides Citrix) has cause to be interested in the 3.0.x branch at this point. If not it seems harmless to delete it, and push focus to master and a new 4.0.x branch.
-kevin
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Robert Schweikert <rj...@suse.com>.
On 06/01/2012 10:55 AM, Wido den Hollander wrote:
> Hi,
>
> On 06/01/2012 04:37 PM, Robert Schweikert wrote:
>> On 05/31/2012 01:35 PM, David Nalley wrote:
>>> On Thu, May 31, 2012 at 8:15 AM, Robert Schweikert<rj...@suse.com>
>>> wrote:
>>>> On 05/31/2012 12:35 AM, Kevin Kluge wrote:
>>>>>
>>>>> The master branch hasn't diverged much from the 3.0.x branch at this
>>>>> point. I can't name any divergence off the top of my head. I would
>>>>> expect
>>>>> 3.0.x to be more stable, but if there is another reason to go forth
>>>>> with
>>>>> master then I wouldn't stop that for stability reasons.
>>>>>
>>>>>> New features going to master for 4.1.x (though our focus should
>>>>>> really
>>>>>> be on
>>>>>> getting an ASF-acceptable release out) Rename the 3.0.x branch to
>>>>>> 4.0.x
>>>>>> to
>>>>>> reflect reality.
>>>>>
>>>>>
>>>>> Renaming the branch will create confusion. The previous 3.0.x releases
>>>>> have already been done off of it so all the committers (and anyone
>>>>> else that
>>>>> has been looking at the code) are expecting this to be the 3.0.x
>>>>> release
>>>>> set. We could plausibly cut a 4.0.0 and future 4.0.x releases off
>>>>> the 3.0.x
>>>>> branch. That is a little odd but (IMO) less confusing than renaming
>>>>> the
>>>>> branch out from under people.
>>>>>
>>>>> We could also take a 4.0.x branch off 3.0.x or master. That leaves
>>>>> open
>>>>> the option of a later 3.0.x release on the 3.0.x branch. That seems
>>>>> the
>>>>> cleanest approach to me, but it would add some additional branch
>>>>> management
>>>>> overhead if fixes are needed in both 3.0.x and 4.0.x.
>>>>>
>>>>> I might have a slight preference to branching 4.0.x off master.
>>>>> Then we
>>>>> would establish a pattern that major releases get branched from
>>>>> master, as
>>>>> was done for 3.0.0 and 4.0.0. This would extend naturally into
>>>>> 5.0.0, etc.
>>>>> and is easy to explain to new committers.
>>>>
>>>>
>>>> I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of
>>>> master is
>>>> confusing. We should always branch major release branches off master.
>>>> This
>>>> does not mean we have to branch 4.0.x of HEAD in master, we can
>>>> choose an
>>>> earlier commit in master if there is concern that HEAD has some
>>>> instabilities.
>>>>
>>>> My $0.02
>>>> Robert
>>>
>>> OK - I can see the logic in that. Soooo - do we need the 3.0.x branch
>>> around anymore? Or perhaps better put - do we intend to use it - even
>>> if we don't purge it?
>>
>> Well, that's kind off a Citrix question. Is Citrix interested in having
>> a public branch to work in? From a community perspective it woudl appear
>> that only the master branch is of interest plus any feature branches
>> that are public.
>
> I don't get the Citrix question?
Cirtix has released/is releasing their product from the 3.0.x branch. It
is AFAIK immaterial to the community. However, if Citrix is interested
in keeping the 3.0.x branch in the open on the Apache git server, the
community should not remove the branch as Cirtrix is after all also a
member of the community.
Thus the Citrix connection and the relevance to this discussion.
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Wido den Hollander <wi...@widodh.nl>.
Hi,
On 06/01/2012 04:37 PM, Robert Schweikert wrote:
> On 05/31/2012 01:35 PM, David Nalley wrote:
>> On Thu, May 31, 2012 at 8:15 AM, Robert Schweikert<rj...@suse.com>
>> wrote:
>>> On 05/31/2012 12:35 AM, Kevin Kluge wrote:
>>>>
>>>> The master branch hasn't diverged much from the 3.0.x branch at this
>>>> point. I can't name any divergence off the top of my head. I would
>>>> expect
>>>> 3.0.x to be more stable, but if there is another reason to go forth
>>>> with
>>>> master then I wouldn't stop that for stability reasons.
>>>>
>>>>> New features going to master for 4.1.x (though our focus should really
>>>>> be on
>>>>> getting an ASF-acceptable release out) Rename the 3.0.x branch to
>>>>> 4.0.x
>>>>> to
>>>>> reflect reality.
>>>>
>>>>
>>>> Renaming the branch will create confusion. The previous 3.0.x releases
>>>> have already been done off of it so all the committers (and anyone
>>>> else that
>>>> has been looking at the code) are expecting this to be the 3.0.x
>>>> release
>>>> set. We could plausibly cut a 4.0.0 and future 4.0.x releases off
>>>> the 3.0.x
>>>> branch. That is a little odd but (IMO) less confusing than renaming the
>>>> branch out from under people.
>>>>
>>>> We could also take a 4.0.x branch off 3.0.x or master. That leaves open
>>>> the option of a later 3.0.x release on the 3.0.x branch. That seems the
>>>> cleanest approach to me, but it would add some additional branch
>>>> management
>>>> overhead if fixes are needed in both 3.0.x and 4.0.x.
>>>>
>>>> I might have a slight preference to branching 4.0.x off master. Then we
>>>> would establish a pattern that major releases get branched from
>>>> master, as
>>>> was done for 3.0.0 and 4.0.0. This would extend naturally into
>>>> 5.0.0, etc.
>>>> and is easy to explain to new committers.
>>>
>>>
>>> I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of master is
>>> confusing. We should always branch major release branches off master.
>>> This
>>> does not mean we have to branch 4.0.x of HEAD in master, we can
>>> choose an
>>> earlier commit in master if there is concern that HEAD has some
>>> instabilities.
>>>
>>> My $0.02
>>> Robert
>>
>> OK - I can see the logic in that. Soooo - do we need the 3.0.x branch
>> around anymore? Or perhaps better put - do we intend to use it - even
>> if we don't purge it?
>
> Well, that's kind off a Citrix question. Is Citrix interested in having
> a public branch to work in? From a community perspective it woudl appear
> that only the master branch is of interest plus any feature branches
> that are public.
I don't get the Citrix question? CloudStack is switching to an Apache
project.
If some people inside Citrix want to work in their own private
repository that's fine, but there will be no "special" Citrix branch of
CloudStack?
>
>> A couple of follow on questions - when should we
>> branch master to build 4.0.x?
>
> I am generally in favor of a "branch as late as possible" model to avoid
> duplicate work (2 commits). However there are also good reasons to
> "branch early" as this model tends to have less impact on new feature
> development. For the first go around, intended mostly for "clean up
> tasks" the branch timing is probably less important.
I agree with the "branch as late as possible". I'd say stick with the
master branch for all the relevant work and build new features in their
down branch.
When those features are ready you merge them into the master and tag the
master to v4.0.0
I personally don't like working in multiple branches as merging them
back again is not that easy, they can diverge to much from each other.
Wido
>
>
> Later,
> Robert
>
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Robert Schweikert <rj...@suse.com>.
On 05/31/2012 01:35 PM, David Nalley wrote:
> On Thu, May 31, 2012 at 8:15 AM, Robert Schweikert<rj...@suse.com> wrote:
>> On 05/31/2012 12:35 AM, Kevin Kluge wrote:
>>>
>>> The master branch hasn't diverged much from the 3.0.x branch at this
>>> point. I can't name any divergence off the top of my head. I would expect
>>> 3.0.x to be more stable, but if there is another reason to go forth with
>>> master then I wouldn't stop that for stability reasons.
>>>
>>>> New features going to master for 4.1.x (though our focus should really
>>>> be on
>>>> getting an ASF-acceptable release out) Rename the 3.0.x branch to 4.0.x
>>>> to
>>>> reflect reality.
>>>
>>>
>>> Renaming the branch will create confusion. The previous 3.0.x releases
>>> have already been done off of it so all the committers (and anyone else that
>>> has been looking at the code) are expecting this to be the 3.0.x release
>>> set. We could plausibly cut a 4.0.0 and future 4.0.x releases off the 3.0.x
>>> branch. That is a little odd but (IMO) less confusing than renaming the
>>> branch out from under people.
>>>
>>> We could also take a 4.0.x branch off 3.0.x or master. That leaves open
>>> the option of a later 3.0.x release on the 3.0.x branch. That seems the
>>> cleanest approach to me, but it would add some additional branch management
>>> overhead if fixes are needed in both 3.0.x and 4.0.x.
>>>
>>> I might have a slight preference to branching 4.0.x off master. Then we
>>> would establish a pattern that major releases get branched from master, as
>>> was done for 3.0.0 and 4.0.0. This would extend naturally into 5.0.0, etc.
>>> and is easy to explain to new committers.
>>
>>
>> I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of master is
>> confusing. We should always branch major release branches off master. This
>> does not mean we have to branch 4.0.x of HEAD in master, we can choose an
>> earlier commit in master if there is concern that HEAD has some
>> instabilities.
>>
>> My $0.02
>> Robert
>
> OK - I can see the logic in that. Soooo - do we need the 3.0.x branch
> around anymore? Or perhaps better put - do we intend to use it - even
> if we don't purge it?
Well, that's kind off a Citrix question. Is Citrix interested in having
a public branch to work in? From a community perspective it woudl appear
that only the master branch is of interest plus any feature branches
that are public.
> A couple of follow on questions - when should we
> branch master to build 4.0.x?
I am generally in favor of a "branch as late as possible" model to avoid
duplicate work (2 commits). However there are also good reasons to
"branch early" as this model tends to have less impact on new feature
development. For the first go around, intended mostly for "clean up
tasks" the branch timing is probably less important.
Later,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by David Nalley <da...@gnsa.us>.
On Thu, May 31, 2012 at 8:15 AM, Robert Schweikert <rj...@suse.com> wrote:
> On 05/31/2012 12:35 AM, Kevin Kluge wrote:
>>
>> The master branch hasn't diverged much from the 3.0.x branch at this
>> point. I can't name any divergence off the top of my head. I would expect
>> 3.0.x to be more stable, but if there is another reason to go forth with
>> master then I wouldn't stop that for stability reasons.
>>
>>> New features going to master for 4.1.x (though our focus should really
>>> be on
>>> getting an ASF-acceptable release out) Rename the 3.0.x branch to 4.0.x
>>> to
>>> reflect reality.
>>
>>
>> Renaming the branch will create confusion. The previous 3.0.x releases
>> have already been done off of it so all the committers (and anyone else that
>> has been looking at the code) are expecting this to be the 3.0.x release
>> set. We could plausibly cut a 4.0.0 and future 4.0.x releases off the 3.0.x
>> branch. That is a little odd but (IMO) less confusing than renaming the
>> branch out from under people.
>>
>> We could also take a 4.0.x branch off 3.0.x or master. That leaves open
>> the option of a later 3.0.x release on the 3.0.x branch. That seems the
>> cleanest approach to me, but it would add some additional branch management
>> overhead if fixes are needed in both 3.0.x and 4.0.x.
>>
>> I might have a slight preference to branching 4.0.x off master. Then we
>> would establish a pattern that major releases get branched from master, as
>> was done for 3.0.0 and 4.0.0. This would extend naturally into 5.0.0, etc.
>> and is easy to explain to new committers.
>
>
> I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of master is
> confusing. We should always branch major release branches off master. This
> does not mean we have to branch 4.0.x of HEAD in master, we can choose an
> earlier commit in master if there is concern that HEAD has some
> instabilities.
>
> My $0.02
> Robert
OK - I can see the logic in that. Soooo - do we need the 3.0.x branch
around anymore? Or perhaps better put - do we intend to use it - even
if we don't purge it? A couple of follow on questions - when should we
branch master to build 4.0.x?
--David
Re: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Robert Schweikert <rj...@suse.com>.
On 05/31/2012 12:35 AM, Kevin Kluge wrote:
> The master branch hasn't diverged much from the 3.0.x branch at this point. I can't name any divergence off the top of my head. I would expect 3.0.x to be more stable, but if there is another reason to go forth with master then I wouldn't stop that for stability reasons.
>
>> New features going to master for 4.1.x (though our focus should really be on
>> getting an ASF-acceptable release out) Rename the 3.0.x branch to 4.0.x to
>> reflect reality.
>
> Renaming the branch will create confusion. The previous 3.0.x releases have already been done off of it so all the committers (and anyone else that has been looking at the code) are expecting this to be the 3.0.x release set. We could plausibly cut a 4.0.0 and future 4.0.x releases off the 3.0.x branch. That is a little odd but (IMO) less confusing than renaming the branch out from under people.
>
> We could also take a 4.0.x branch off 3.0.x or master. That leaves open the option of a later 3.0.x release on the 3.0.x branch. That seems the cleanest approach to me, but it would add some additional branch management overhead if fixes are needed in both 3.0.x and 4.0.x.
>
> I might have a slight preference to branching 4.0.x off master. Then we would establish a pattern that major releases get branched from master, as was done for 3.0.0 and 4.0.0. This would extend naturally into 5.0.0, etc. and is easy to explain to new committers.
I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of master is
confusing. We should always branch major release branches off master.
This does not mean we have to branch 4.0.x of HEAD in master, we can
choose an earlier commit in master if there is concern that HEAD has
some instabilities.
My $0.02
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
RE: [DISCUSS] where to begin the process for Apache CloudStack 4.0.0
Posted by Kevin Kluge <Ke...@citrix.com>.
The master branch hasn't diverged much from the 3.0.x branch at this point. I can't name any divergence off the top of my head. I would expect 3.0.x to be more stable, but if there is another reason to go forth with master then I wouldn't stop that for stability reasons.
> New features going to master for 4.1.x (though our focus should really be on
> getting an ASF-acceptable release out) Rename the 3.0.x branch to 4.0.x to
> reflect reality.
Renaming the branch will create confusion. The previous 3.0.x releases have already been done off of it so all the committers (and anyone else that has been looking at the code) are expecting this to be the 3.0.x release set. We could plausibly cut a 4.0.0 and future 4.0.x releases off the 3.0.x branch. That is a little odd but (IMO) less confusing than renaming the branch out from under people.
We could also take a 4.0.x branch off 3.0.x or master. That leaves open the option of a later 3.0.x release on the 3.0.x branch. That seems the cleanest approach to me, but it would add some additional branch management overhead if fixes are needed in both 3.0.x and 4.0.x.
I might have a slight preference to branching 4.0.x off master. Then we would establish a pattern that major releases get branched from master, as was done for 3.0.0 and 4.0.0. This would extend naturally into 5.0.0, etc. and is easy to explain to new committers. But someone should take the master code for a spin and check the stability to confirm my first paragraph...
-kevin