You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2013/02/02 02:57:32 UTC
[ACS41] 4.1 branch created
Hi all,
Looks like Kelvin finished the merge of javelin into master, so I went
ahead and branched master for the 4.1 release (after mistakenly doing
the same for 4.2... jumping the gun by a few months ;-) )
This isn't a "locked down" branch right now, but I'd ask committers to
respect the feature and improvement freeze in that branch. Bug fixes,
doc updates and other release stabilization activities are obviously
expected. Committers should feel free to commit directly into that
branch until we hit the code freeze date).
For non-commiter contributors, it might be best to actually send in
patches that have been built against the 4.1 branch. Committers
taking these fixes should also consider applying them to master. If
there are conflicts in master (which may happen, as there were a
couple of code-base refactoring activities, like switching packages
from com.cloud to org.apache.cloudstack), apply the fix into 4.1
anyway, and inform the submitter that the patch has conflicts with
master to get that sorted out (or you can fix it yourself).
Shout if you have questions / concerns / flames.
-chip
Re: [ACS41] 4.1 branch created
Posted by Sheng Yang <sh...@yasker.org>.
On Sun, Feb 3, 2013 at 10:46 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Sun, Feb 3, 2013 at 2:03 AM, Hugo Trippaers
> <HT...@schubergphilis.com> wrote:
>> Heya all,
>>
>> I find it way too early to cut a 4.1 release branch. I now that this is what we agreed to do, but the way we are going at it doesn't sit right with me. The simple fact that we have some mayor code changes forced into master just are the freeze (javelin, ucs and ipv6) and immediately create a release branch isn't the way to go if we want a stable release. There are numerous issues with the current state of master and hence the 4.1 branch like regression bugs in the maven system that have been introduced by merging in old maven code with Javelin.
>>
>> I personally don't feel we are in shape yet to make the current state of master into a release worthy branch as it would seriously impair the ability of people to go in and fix stuff as we have to deal with a release manager before patches are going into 4.1 branch.
>>
>
> I disagree with the statement that it's too early to have cut the
> release branch, but I think we have different understandings of my
> intent in cutting that branch. I completely agree that it's not a
> release quality branch right now. Far from it. This quality level is
> problematic to me, but it's a different issue from freeing up master
> for new features and further refactoring work that will be part of the
> feature release that's after 4.1.0.
>
> The intent of the 4.1 branch is to (1) freeze new features from going
> into the 4.1 release, (2) provide us with a branch to focus our
> release stabilization efforts, and (3) allow features to continue to
> merge into master for our next feature release after 4.1.0 (which may
> be 5.0.0 or 4.2.0, depending on some of the API discussions).
>
> Also, one other key point. I'm not interested in taking
> responsibility for cherry picking changes from master to 4.1 right
> now, and will not be doing so! The working schedule for 4.1.0 has
> that level of branch freeze only after 2013-02-28.
>
> Yes, cutting a branch now means that committers have to take extra
> time to ensure fixes go into master AND 4.1. I'd rather have that
> situation, than continue to block new features and architectural
> modifications in master. The best way for time-based releases to get
> better, is for us to ensure that changes happen as early in the cycle
> as possible. We flooded changes into master just before the agreed
> upon cutoff date, which is at best sub-optimal.
I am completely agree with Chip's statement here.
It's a feature freeze branch, which still means tons of bugs are
ahead. Take Linux kernel for example, Linus open the merge window, and
pull from other contributor almost every 3 months - last 2 or 3 weeks
each(thousands of commits I think), then cut RC1, which means, feature
is done, now only bug fixes for these features. Most of time, Linux
kernel RC1 is only compilable, and totally broken for everyone. That's
what we need to fix after that - we just need to ensure that no
feature after the cut, which is the source of never
"convergence"(stable). That's the purpose of branch. The stabilization
of Linux kernel would take mostly three months, until RC6 or RC7
mostly.
Also, I am competely agree with Chip's saying of cherry-picking. It's
too early for cherry-picking, just make no sense for release manager
to pick up probably tens of commits per day. That's not expected.
Developer would take the responsibility.
--Sheng
>
>> In fact i feel so strong about it that i'm half a mind to start a vote to remove current 4.1 branch and set the next date to branch of from to a week from now. I don't feel confident that the current state of the branch will result in a stable release without some serious work going into it and that should happen on master.
>>
>
> So you don't actually have to start a vote on it. You've got the
> right to veto the 4.1 branch if you'd like to. ;-) Please consider my
> other points before taking that action though, and please include an
> alternative plan!
>
>> Please have a look at the number of unit tests that have been pushed with the merges mentioned above and the increase in code coverage reported by cobertura. Both of which show hardly any changes even though mayor rewrites have been introduced in the inner workings of CloudStack. I would expect to see for example detailed unittests on the handling of IPv6 and numerous tests to ensure that the new spring framework is up to task. Currently i feel like i'm being force into releasing something that i don't trust yet.
>>
>
> I completely concur with the concerns about unit testing. I'm
> actually pretty disappointed in the lack of attention to including
> automated tests of some sort with each new feature. This lack of
> attention seems to contradict what I understood to be the general
> community consensus that we need to include tests with every new
> feature. How do we want to fix this moving forward? Should the
> committers veto any commit that doesn't increase test coverage
> wherever possible?
>
>> At collab12 one of the main themes that i was hearing all around what confidence in the code base by testing. I would like the 4.1 release to be a show case if that way of thinking. We have put out a very nice 4.0.0 release that the people i meet are very happy about. The next release should be even better and inspire confidence that we are a project that is able to deliver well tested and stable releases.
>>
>> Sorry for being such an ass about this, but we are all working very hard on getting this release out and i really want this to be the best release possible and not just a bunch of bolted-on features.
>
> You're not being an ass at all. I think you're very appropriately
> raising the right concerns. We just disagree with the intent of the
> branch!
>
>>
>> So what do you guys think?
>>
>> Cheers,
>>
>> Hugo
RE: [ACS41] 4.1 branch created
Posted by Sudha Ponnaganti <su...@citrix.com>.
+1 for 4.1 branching. Master would not be stable and closing 4.1 would be very difficult if the branch is cut much later as teams would be checking in new features in to master.
There is of course possibility to hold these features by other means like holding merge and holding review branches.
We are running automated regressions offline on master and you must have been seeing some defects coming in since last week. Will be testing new features starting this week. Teams have posted new test plans. Waiting on review feedback but not holding back because of that.
Thanks
/sudha
-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com]
Sent: Sunday, February 03, 2013 10:47 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [ACS41] 4.1 branch created
On Sun, Feb 3, 2013 at 2:03 AM, Hugo Trippaers <HT...@schubergphilis.com> wrote:
> Heya all,
>
> I find it way too early to cut a 4.1 release branch. I now that this is what we agreed to do, but the way we are going at it doesn't sit right with me. The simple fact that we have some mayor code changes forced into master just are the freeze (javelin, ucs and ipv6) and immediately create a release branch isn't the way to go if we want a stable release. There are numerous issues with the current state of master and hence the 4.1 branch like regression bugs in the maven system that have been introduced by merging in old maven code with Javelin.
>
> I personally don't feel we are in shape yet to make the current state of master into a release worthy branch as it would seriously impair the ability of people to go in and fix stuff as we have to deal with a release manager before patches are going into 4.1 branch.
>
I disagree with the statement that it's too early to have cut the release branch, but I think we have different understandings of my intent in cutting that branch. I completely agree that it's not a release quality branch right now. Far from it. This quality level is problematic to me, but it's a different issue from freeing up master for new features and further refactoring work that will be part of the feature release that's after 4.1.0.
The intent of the 4.1 branch is to (1) freeze new features from going into the 4.1 release, (2) provide us with a branch to focus our release stabilization efforts, and (3) allow features to continue to merge into master for our next feature release after 4.1.0 (which may be 5.0.0 or 4.2.0, depending on some of the API discussions).
Also, one other key point. I'm not interested in taking responsibility for cherry picking changes from master to 4.1 right now, and will not be doing so! The working schedule for 4.1.0 has that level of branch freeze only after 2013-02-28.
Yes, cutting a branch now means that committers have to take extra time to ensure fixes go into master AND 4.1. I'd rather have that situation, than continue to block new features and architectural modifications in master. The best way for time-based releases to get better, is for us to ensure that changes happen as early in the cycle as possible. We flooded changes into master just before the agreed upon cutoff date, which is at best sub-optimal.
> In fact i feel so strong about it that i'm half a mind to start a vote to remove current 4.1 branch and set the next date to branch of from to a week from now. I don't feel confident that the current state of the branch will result in a stable release without some serious work going into it and that should happen on master.
>
So you don't actually have to start a vote on it. You've got the right to veto the 4.1 branch if you'd like to. ;-) Please consider my other points before taking that action though, and please include an alternative plan!
> Please have a look at the number of unit tests that have been pushed with the merges mentioned above and the increase in code coverage reported by cobertura. Both of which show hardly any changes even though mayor rewrites have been introduced in the inner workings of CloudStack. I would expect to see for example detailed unittests on the handling of IPv6 and numerous tests to ensure that the new spring framework is up to task. Currently i feel like i'm being force into releasing something that i don't trust yet.
>
I completely concur with the concerns about unit testing. I'm actually pretty disappointed in the lack of attention to including automated tests of some sort with each new feature. This lack of attention seems to contradict what I understood to be the general community consensus that we need to include tests with every new feature. How do we want to fix this moving forward? Should the committers veto any commit that doesn't increase test coverage wherever possible?
> At collab12 one of the main themes that i was hearing all around what confidence in the code base by testing. I would like the 4.1 release to be a show case if that way of thinking. We have put out a very nice 4.0.0 release that the people i meet are very happy about. The next release should be even better and inspire confidence that we are a project that is able to deliver well tested and stable releases.
>
> Sorry for being such an ass about this, but we are all working very hard on getting this release out and i really want this to be the best release possible and not just a bunch of bolted-on features.
You're not being an ass at all. I think you're very appropriately raising the right concerns. We just disagree with the intent of the branch!
>
> So what do you guys think?
>
> Cheers,
>
> Hugo
Re: [ACS41] 4.1 branch created
Posted by Chip Childers <ch...@sungard.com>.
On Sun, Feb 3, 2013 at 2:03 AM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> Heya all,
>
> I find it way too early to cut a 4.1 release branch. I now that this is what we agreed to do, but the way we are going at it doesn't sit right with me. The simple fact that we have some mayor code changes forced into master just are the freeze (javelin, ucs and ipv6) and immediately create a release branch isn't the way to go if we want a stable release. There are numerous issues with the current state of master and hence the 4.1 branch like regression bugs in the maven system that have been introduced by merging in old maven code with Javelin.
>
> I personally don't feel we are in shape yet to make the current state of master into a release worthy branch as it would seriously impair the ability of people to go in and fix stuff as we have to deal with a release manager before patches are going into 4.1 branch.
>
I disagree with the statement that it's too early to have cut the
release branch, but I think we have different understandings of my
intent in cutting that branch. I completely agree that it's not a
release quality branch right now. Far from it. This quality level is
problematic to me, but it's a different issue from freeing up master
for new features and further refactoring work that will be part of the
feature release that's after 4.1.0.
The intent of the 4.1 branch is to (1) freeze new features from going
into the 4.1 release, (2) provide us with a branch to focus our
release stabilization efforts, and (3) allow features to continue to
merge into master for our next feature release after 4.1.0 (which may
be 5.0.0 or 4.2.0, depending on some of the API discussions).
Also, one other key point. I'm not interested in taking
responsibility for cherry picking changes from master to 4.1 right
now, and will not be doing so! The working schedule for 4.1.0 has
that level of branch freeze only after 2013-02-28.
Yes, cutting a branch now means that committers have to take extra
time to ensure fixes go into master AND 4.1. I'd rather have that
situation, than continue to block new features and architectural
modifications in master. The best way for time-based releases to get
better, is for us to ensure that changes happen as early in the cycle
as possible. We flooded changes into master just before the agreed
upon cutoff date, which is at best sub-optimal.
> In fact i feel so strong about it that i'm half a mind to start a vote to remove current 4.1 branch and set the next date to branch of from to a week from now. I don't feel confident that the current state of the branch will result in a stable release without some serious work going into it and that should happen on master.
>
So you don't actually have to start a vote on it. You've got the
right to veto the 4.1 branch if you'd like to. ;-) Please consider my
other points before taking that action though, and please include an
alternative plan!
> Please have a look at the number of unit tests that have been pushed with the merges mentioned above and the increase in code coverage reported by cobertura. Both of which show hardly any changes even though mayor rewrites have been introduced in the inner workings of CloudStack. I would expect to see for example detailed unittests on the handling of IPv6 and numerous tests to ensure that the new spring framework is up to task. Currently i feel like i'm being force into releasing something that i don't trust yet.
>
I completely concur with the concerns about unit testing. I'm
actually pretty disappointed in the lack of attention to including
automated tests of some sort with each new feature. This lack of
attention seems to contradict what I understood to be the general
community consensus that we need to include tests with every new
feature. How do we want to fix this moving forward? Should the
committers veto any commit that doesn't increase test coverage
wherever possible?
> At collab12 one of the main themes that i was hearing all around what confidence in the code base by testing. I would like the 4.1 release to be a show case if that way of thinking. We have put out a very nice 4.0.0 release that the people i meet are very happy about. The next release should be even better and inspire confidence that we are a project that is able to deliver well tested and stable releases.
>
> Sorry for being such an ass about this, but we are all working very hard on getting this release out and i really want this to be the best release possible and not just a bunch of bolted-on features.
You're not being an ass at all. I think you're very appropriately
raising the right concerns. We just disagree with the intent of the
branch!
>
> So what do you guys think?
>
> Cheers,
>
> Hugo
Re: [ACS41] 4.1 branch created
Posted by Chip Childers <ch...@sungard.com>.
On Sun, Feb 3, 2013 at 2:37 AM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> Hey Marcus,
>
> We do have another month or soto fix things. My main worry is the amount of things that we still have to fix. The current consensus is that we have a release manager who does the cherry picking of fixes from master to the branch. If we have sizable number of fixes this might quickly become a bottle neck and unreasonably burden the poor guy assigned to the job (remember that its a volunteer run project). If we are able to work directly on the 4.1 branch we run the risk that 4.1 and master diverge to a point where they are increasingly difficult to realign and we get the same issues as with the javelin merge when we finish up the 4.1 release and get in shape for the 4.2 release.
>
I already made this point earlier, but I'll reiterate. I'm not going
to take responsibility for cherry-picking from master right now.
That's not until March.
All committers (and even contributors) need to take responsibility for
the 4.1 branch being in sync with master right now.
-chip
Re: [ACS41] 4.1 branch created
Posted by Marcus Sorensen <sh...@gmail.com>.
Oh yes, of course. What these people would be looking for are bug fix
releases. They want to wait for 4.0.1, not 4.1.0.
On Feb 3, 2013 12:54 AM, "Marcus Sorensen" <sh...@gmail.com> wrote:
> One more thing, I think people waiting for non .0 releases probably
> will be disappointed. My impression was that our versioning doesn't
> really work that way, major revisions are more related to API
> compatibility, correct?
>
> On Sun, Feb 3, 2013 at 12:51 AM, Rohit Yadav <bh...@apache.org> wrote:
> > On Sun, Feb 3, 2013 at 1:07 PM, Hugo Trippaers
> > <HT...@schubergphilis.com> wrote:
> >> Hey Marcus,
> >>
> >> We do have another month or soto fix things. My main worry is the
> amount of things that we still have to fix. The current consensus is that
> we have a release manager who does the cherry picking of fixes from master
> to the branch. If we have sizable number of fixes this might quickly become
> a bottle neck and unreasonably burden the poor guy assigned to the job
> (remember that its a volunteer run project). If we are able to work
> directly on the 4.1 branch we run the risk that 4.1 and master diverge to a
> point where they are increasingly difficult to realign and we get the same
> issues as with the javelin merge when we finish up the 4.1 release and get
> in shape for the 4.2 release.
> >
> > As per the timeline, we have roughly two months (~end of march) till
> > 4.1 release. So, initially I thought about just working for another
> > month on master and then creating the 4.1 branch, but then the issue
> > is with code freeze, people may want to commit new features. While I
> > would just want what you're suggesting, but can we enforce that no one
> > commits any new feature work on master? (this is doable if we ask
> > people to work on their feature branches).
> >
> >> Normally i would be al for sticking to the process, but in this
> particular case we have several large features (and in the case of javelin
> radical architecture changes) pushed in at the very last moment possible.
> Combined with the poor shape of testing at the moment this calls for extra
> caution. This is going to be the 4.1 release, in my experience a lot of
> enterprise folks will hold off on .0 release and wait for .1 releases
> before the decide to upgrade or not. It's also our second release and folks
> might be waiting for that as well, not really trusting our first release
> yet. So i'm really aiming for this release to be the highest quality
> possible, i personally find this more important than sticking to the plan
> (at this time). And as you mentioned, the plan actually calls for large
> features to be merged at the beginning of the cycle, not at the end in a
> rush.
> >
> > IMO 4.2 would be the actual version we would see radical changes,
> > hoping we fix a lot of leftover tasks, adapt the codebase as per new
> > design.
> >
> > Regards.
> >
> >>
> >> Cheers,
> >>
> >> Hugo
> >>
> >> ________________________________________
> >> From: Marcus Sorensen [shadowsor@gmail.com]
> >> Sent: Sunday, February 03, 2013 8:23 AM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: RE: [ACS41] 4.1 branch created
> >>
> >> I understand the reservations as well, and I think everyone has reached
> the
> >> consensus that we should both include better test coverage and reserve
> >> large changes for the beginning of the dev cycle. But my impression was
> >> that this was just a feature freeze, and we really have another few
> months
> >> to harden things.
> >>
> >> I'm not sure it makes sense to hold off on the cut, as if we do, I think
> >> we'd be pushing people off from merging features to master (or risk
> >> continuously pushing out), and we can just address the things anyway and
> >> pull them into the 4.1 branch without interrupting development. I wasn't
> >> under the impression that the 4.1 branch would be hard to work on, just
> >> that we shouldn't be adding features.
> >>
> >> Are you thinking there should be a regular moratorium or something
> similar
> >> just before the cut, so that the quality of the features as a whole can
> be
> >> evaluated, or are you just concerned that the last minute features
> didn't
> >> get proper review? I think that as long as there's a time-based release
> >> were going to have features rushed, we either need to be OK with it and
> >> allow for time and ability to fix it afterward, or have some very
> stringent
> >> quality control prior to merge. We can maybe start with the former and
> work
> >> toward the latter.
> >> On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <
> HTrippaers@schubergphilis.com>
> >> wrote:
> >>
> >>> Heya all,
> >>>
> >>> I find it way too early to cut a 4.1 release branch. I now that this is
> >>> what we agreed to do, but the way we are going at it doesn't sit right
> with
> >>> me. The simple fact that we have some mayor code changes forced into
> master
> >>> just are the freeze (javelin, ucs and ipv6) and immediately create a
> >>> release branch isn't the way to go if we want a stable release. There
> are
> >>> numerous issues with the current state of master and hence the 4.1
> branch
> >>> like regression bugs in the maven system that have been introduced by
> >>> merging in old maven code with Javelin.
> >>>
> >>> I personally don't feel we are in shape yet to make the current state
> of
> >>> master into a release worthy branch as it would seriously impair the
> >>> ability of people to go in and fix stuff as we have to deal with a
> release
> >>> manager before patches are going into 4.1 branch.
> >>>
> >>> In fact i feel so strong about it that i'm half a mind to start a vote
> to
> >>> remove current 4.1 branch and set the next date to branch of from to a
> week
> >>> from now. I don't feel confident that the current state of the branch
> will
> >>> result in a stable release without some serious work going into it and
> that
> >>> should happen on master.
> >>>
> >>> Please have a look at the number of unit tests that have been pushed
> with
> >>> the merges mentioned above and the increase in code coverage reported
> by
> >>> cobertura. Both of which show hardly any changes even though mayor
> rewrites
> >>> have been introduced in the inner workings of CloudStack. I would
> expect to
> >>> see for example detailed unittests on the handling of IPv6 and numerous
> >>> tests to ensure that the new spring framework is up to task. Currently
> i
> >>> feel like i'm being force into releasing something that i don't trust
> yet.
> >>>
> >>> At collab12 one of the main themes that i was hearing all around what
> >>> confidence in the code base by testing. I would like the 4.1 release
> to be
> >>> a show case if that way of thinking. We have put out a very nice 4.0.0
> >>> release that the people i meet are very happy about. The next release
> >>> should be even better and inspire confidence that we are a project
> that is
> >>> able to deliver well tested and stable releases.
> >>>
> >>> Sorry for being such an ass about this, but we are all working very
> hard
> >>> on getting this release out and i really want this to be the best
> release
> >>> possible and not just a bunch of bolted-on features.
> >>>
> >>> So what do you guys think?
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
> >>>
> >>> ________________________________________
> >>> From: Chip Childers [chip.childers@sungard.com]
> >>> Sent: Saturday, February 02, 2013 2:27 PM
> >>> To: <cl...@incubator.apache.org>
> >>> Subject: Re: [ACS41] 4.1 branch created
> >>>
> >>> On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
> >>>
> >>> > Does this mean features havent been merged into master will be
> postponed
> >>> to 4.2?
> >>> >
> >>>
> >>> Yes. That was the idea with using a time-based release planning
> process.
> >>>
> >>> > -Mice
> >>> >
> >>> > 2013/2/2 Alex Huang <Al...@citrix.com>:
> >>> >> Kelven also mentioned he had to merge a few times because code was
> >>> being changed in master. It is supposed to be frozen until this
> message
> >>> from Chip. Please respect the instructions the release manager has
> given
> >>> out. Master is now open but 4.1 is now frozen. Please respect this
> even
> >>> though you can check-in to 4.1. If we find "features" being sneaked
> in,
> >>> then it would make sense for us to lockdown 4.1, which makes bug
> fixing and
> >>> unit testing checkins a laborious process.
> >>> >>
> >>> >> --Alex
> >>> >>
> >>> >>> -----Original Message-----
> >>> >>> From: Chip Childers [mailto:chip.childers@sungard.com]
> >>> >>> Sent: Friday, February 01, 2013 5:58 PM
> >>> >>> To: cloudstack-dev@incubator.apache.org
> >>> >>> Subject: [ACS41] 4.1 branch created
> >>> >>>
> >>> >>> Hi all,
> >>> >>>
> >>> >>> Looks like Kelvin finished the merge of javelin into master, so I
> went
> >>> >>> ahead and branched master for the 4.1 release (after mistakenly
> doing
> >>> >>> the same for 4.2... jumping the gun by a few months ;-) )
> >>> >>>
> >>> >>> This isn't a "locked down" branch right now, but I'd ask
> committers to
> >>> >>> respect the feature and improvement freeze in that branch. Bug
> fixes,
> >>> >>> doc updates and other release stabilization activities are
> obviously
> >>> >>> expected. Committers should feel free to commit directly into that
> >>> >>> branch until we hit the code freeze date).
> >>> >>>
> >>> >>> For non-commiter contributors, it might be best to actually send in
> >>> >>> patches that have been built against the 4.1 branch. Committers
> >>> >>> taking these fixes should also consider applying them to master.
> If
> >>> >>> there are conflicts in master (which may happen, as there were a
> >>> >>> couple of code-base refactoring activities, like switching packages
> >>> >>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
> >>> >>> anyway, and inform the submitter that the patch has conflicts with
> >>> >>> master to get that sorted out (or you can fix it yourself).
> >>> >>>
> >>> >>> Shout if you have questions / concerns / flames.
> >>> >>>
> >>> >>> -chip
> >>> >
> >>>
>
Re: [ACS41] 4.1 branch created
Posted by Marcus Sorensen <sh...@gmail.com>.
One more thing, I think people waiting for non .0 releases probably
will be disappointed. My impression was that our versioning doesn't
really work that way, major revisions are more related to API
compatibility, correct?
On Sun, Feb 3, 2013 at 12:51 AM, Rohit Yadav <bh...@apache.org> wrote:
> On Sun, Feb 3, 2013 at 1:07 PM, Hugo Trippaers
> <HT...@schubergphilis.com> wrote:
>> Hey Marcus,
>>
>> We do have another month or soto fix things. My main worry is the amount of things that we still have to fix. The current consensus is that we have a release manager who does the cherry picking of fixes from master to the branch. If we have sizable number of fixes this might quickly become a bottle neck and unreasonably burden the poor guy assigned to the job (remember that its a volunteer run project). If we are able to work directly on the 4.1 branch we run the risk that 4.1 and master diverge to a point where they are increasingly difficult to realign and we get the same issues as with the javelin merge when we finish up the 4.1 release and get in shape for the 4.2 release.
>
> As per the timeline, we have roughly two months (~end of march) till
> 4.1 release. So, initially I thought about just working for another
> month on master and then creating the 4.1 branch, but then the issue
> is with code freeze, people may want to commit new features. While I
> would just want what you're suggesting, but can we enforce that no one
> commits any new feature work on master? (this is doable if we ask
> people to work on their feature branches).
>
>> Normally i would be al for sticking to the process, but in this particular case we have several large features (and in the case of javelin radical architecture changes) pushed in at the very last moment possible. Combined with the poor shape of testing at the moment this calls for extra caution. This is going to be the 4.1 release, in my experience a lot of enterprise folks will hold off on .0 release and wait for .1 releases before the decide to upgrade or not. It's also our second release and folks might be waiting for that as well, not really trusting our first release yet. So i'm really aiming for this release to be the highest quality possible, i personally find this more important than sticking to the plan (at this time). And as you mentioned, the plan actually calls for large features to be merged at the beginning of the cycle, not at the end in a rush.
>
> IMO 4.2 would be the actual version we would see radical changes,
> hoping we fix a lot of leftover tasks, adapt the codebase as per new
> design.
>
> Regards.
>
>>
>> Cheers,
>>
>> Hugo
>>
>> ________________________________________
>> From: Marcus Sorensen [shadowsor@gmail.com]
>> Sent: Sunday, February 03, 2013 8:23 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: [ACS41] 4.1 branch created
>>
>> I understand the reservations as well, and I think everyone has reached the
>> consensus that we should both include better test coverage and reserve
>> large changes for the beginning of the dev cycle. But my impression was
>> that this was just a feature freeze, and we really have another few months
>> to harden things.
>>
>> I'm not sure it makes sense to hold off on the cut, as if we do, I think
>> we'd be pushing people off from merging features to master (or risk
>> continuously pushing out), and we can just address the things anyway and
>> pull them into the 4.1 branch without interrupting development. I wasn't
>> under the impression that the 4.1 branch would be hard to work on, just
>> that we shouldn't be adding features.
>>
>> Are you thinking there should be a regular moratorium or something similar
>> just before the cut, so that the quality of the features as a whole can be
>> evaluated, or are you just concerned that the last minute features didn't
>> get proper review? I think that as long as there's a time-based release
>> were going to have features rushed, we either need to be OK with it and
>> allow for time and ability to fix it afterward, or have some very stringent
>> quality control prior to merge. We can maybe start with the former and work
>> toward the latter.
>> On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
>> wrote:
>>
>>> Heya all,
>>>
>>> I find it way too early to cut a 4.1 release branch. I now that this is
>>> what we agreed to do, but the way we are going at it doesn't sit right with
>>> me. The simple fact that we have some mayor code changes forced into master
>>> just are the freeze (javelin, ucs and ipv6) and immediately create a
>>> release branch isn't the way to go if we want a stable release. There are
>>> numerous issues with the current state of master and hence the 4.1 branch
>>> like regression bugs in the maven system that have been introduced by
>>> merging in old maven code with Javelin.
>>>
>>> I personally don't feel we are in shape yet to make the current state of
>>> master into a release worthy branch as it would seriously impair the
>>> ability of people to go in and fix stuff as we have to deal with a release
>>> manager before patches are going into 4.1 branch.
>>>
>>> In fact i feel so strong about it that i'm half a mind to start a vote to
>>> remove current 4.1 branch and set the next date to branch of from to a week
>>> from now. I don't feel confident that the current state of the branch will
>>> result in a stable release without some serious work going into it and that
>>> should happen on master.
>>>
>>> Please have a look at the number of unit tests that have been pushed with
>>> the merges mentioned above and the increase in code coverage reported by
>>> cobertura. Both of which show hardly any changes even though mayor rewrites
>>> have been introduced in the inner workings of CloudStack. I would expect to
>>> see for example detailed unittests on the handling of IPv6 and numerous
>>> tests to ensure that the new spring framework is up to task. Currently i
>>> feel like i'm being force into releasing something that i don't trust yet.
>>>
>>> At collab12 one of the main themes that i was hearing all around what
>>> confidence in the code base by testing. I would like the 4.1 release to be
>>> a show case if that way of thinking. We have put out a very nice 4.0.0
>>> release that the people i meet are very happy about. The next release
>>> should be even better and inspire confidence that we are a project that is
>>> able to deliver well tested and stable releases.
>>>
>>> Sorry for being such an ass about this, but we are all working very hard
>>> on getting this release out and i really want this to be the best release
>>> possible and not just a bunch of bolted-on features.
>>>
>>> So what do you guys think?
>>>
>>> Cheers,
>>>
>>> Hugo
>>>
>>>
>>> ________________________________________
>>> From: Chip Childers [chip.childers@sungard.com]
>>> Sent: Saturday, February 02, 2013 2:27 PM
>>> To: <cl...@incubator.apache.org>
>>> Subject: Re: [ACS41] 4.1 branch created
>>>
>>> On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
>>>
>>> > Does this mean features havent been merged into master will be postponed
>>> to 4.2?
>>> >
>>>
>>> Yes. That was the idea with using a time-based release planning process.
>>>
>>> > -Mice
>>> >
>>> > 2013/2/2 Alex Huang <Al...@citrix.com>:
>>> >> Kelven also mentioned he had to merge a few times because code was
>>> being changed in master. It is supposed to be frozen until this message
>>> from Chip. Please respect the instructions the release manager has given
>>> out. Master is now open but 4.1 is now frozen. Please respect this even
>>> though you can check-in to 4.1. If we find "features" being sneaked in,
>>> then it would make sense for us to lockdown 4.1, which makes bug fixing and
>>> unit testing checkins a laborious process.
>>> >>
>>> >> --Alex
>>> >>
>>> >>> -----Original Message-----
>>> >>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> >>> Sent: Friday, February 01, 2013 5:58 PM
>>> >>> To: cloudstack-dev@incubator.apache.org
>>> >>> Subject: [ACS41] 4.1 branch created
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> Looks like Kelvin finished the merge of javelin into master, so I went
>>> >>> ahead and branched master for the 4.1 release (after mistakenly doing
>>> >>> the same for 4.2... jumping the gun by a few months ;-) )
>>> >>>
>>> >>> This isn't a "locked down" branch right now, but I'd ask committers to
>>> >>> respect the feature and improvement freeze in that branch. Bug fixes,
>>> >>> doc updates and other release stabilization activities are obviously
>>> >>> expected. Committers should feel free to commit directly into that
>>> >>> branch until we hit the code freeze date).
>>> >>>
>>> >>> For non-commiter contributors, it might be best to actually send in
>>> >>> patches that have been built against the 4.1 branch. Committers
>>> >>> taking these fixes should also consider applying them to master. If
>>> >>> there are conflicts in master (which may happen, as there were a
>>> >>> couple of code-base refactoring activities, like switching packages
>>> >>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
>>> >>> anyway, and inform the submitter that the patch has conflicts with
>>> >>> master to get that sorted out (or you can fix it yourself).
>>> >>>
>>> >>> Shout if you have questions / concerns / flames.
>>> >>>
>>> >>> -chip
>>> >
>>>
Re: [ACS41] 4.1 branch created
Posted by Rohit Yadav <bh...@apache.org>.
On Sun, Feb 3, 2013 at 1:07 PM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> Hey Marcus,
>
> We do have another month or soto fix things. My main worry is the amount of things that we still have to fix. The current consensus is that we have a release manager who does the cherry picking of fixes from master to the branch. If we have sizable number of fixes this might quickly become a bottle neck and unreasonably burden the poor guy assigned to the job (remember that its a volunteer run project). If we are able to work directly on the 4.1 branch we run the risk that 4.1 and master diverge to a point where they are increasingly difficult to realign and we get the same issues as with the javelin merge when we finish up the 4.1 release and get in shape for the 4.2 release.
As per the timeline, we have roughly two months (~end of march) till
4.1 release. So, initially I thought about just working for another
month on master and then creating the 4.1 branch, but then the issue
is with code freeze, people may want to commit new features. While I
would just want what you're suggesting, but can we enforce that no one
commits any new feature work on master? (this is doable if we ask
people to work on their feature branches).
> Normally i would be al for sticking to the process, but in this particular case we have several large features (and in the case of javelin radical architecture changes) pushed in at the very last moment possible. Combined with the poor shape of testing at the moment this calls for extra caution. This is going to be the 4.1 release, in my experience a lot of enterprise folks will hold off on .0 release and wait for .1 releases before the decide to upgrade or not. It's also our second release and folks might be waiting for that as well, not really trusting our first release yet. So i'm really aiming for this release to be the highest quality possible, i personally find this more important than sticking to the plan (at this time). And as you mentioned, the plan actually calls for large features to be merged at the beginning of the cycle, not at the end in a rush.
IMO 4.2 would be the actual version we would see radical changes,
hoping we fix a lot of leftover tasks, adapt the codebase as per new
design.
Regards.
>
> Cheers,
>
> Hugo
>
> ________________________________________
> From: Marcus Sorensen [shadowsor@gmail.com]
> Sent: Sunday, February 03, 2013 8:23 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [ACS41] 4.1 branch created
>
> I understand the reservations as well, and I think everyone has reached the
> consensus that we should both include better test coverage and reserve
> large changes for the beginning of the dev cycle. But my impression was
> that this was just a feature freeze, and we really have another few months
> to harden things.
>
> I'm not sure it makes sense to hold off on the cut, as if we do, I think
> we'd be pushing people off from merging features to master (or risk
> continuously pushing out), and we can just address the things anyway and
> pull them into the 4.1 branch without interrupting development. I wasn't
> under the impression that the 4.1 branch would be hard to work on, just
> that we shouldn't be adding features.
>
> Are you thinking there should be a regular moratorium or something similar
> just before the cut, so that the quality of the features as a whole can be
> evaluated, or are you just concerned that the last minute features didn't
> get proper review? I think that as long as there's a time-based release
> were going to have features rushed, we either need to be OK with it and
> allow for time and ability to fix it afterward, or have some very stringent
> quality control prior to merge. We can maybe start with the former and work
> toward the latter.
> On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
> wrote:
>
>> Heya all,
>>
>> I find it way too early to cut a 4.1 release branch. I now that this is
>> what we agreed to do, but the way we are going at it doesn't sit right with
>> me. The simple fact that we have some mayor code changes forced into master
>> just are the freeze (javelin, ucs and ipv6) and immediately create a
>> release branch isn't the way to go if we want a stable release. There are
>> numerous issues with the current state of master and hence the 4.1 branch
>> like regression bugs in the maven system that have been introduced by
>> merging in old maven code with Javelin.
>>
>> I personally don't feel we are in shape yet to make the current state of
>> master into a release worthy branch as it would seriously impair the
>> ability of people to go in and fix stuff as we have to deal with a release
>> manager before patches are going into 4.1 branch.
>>
>> In fact i feel so strong about it that i'm half a mind to start a vote to
>> remove current 4.1 branch and set the next date to branch of from to a week
>> from now. I don't feel confident that the current state of the branch will
>> result in a stable release without some serious work going into it and that
>> should happen on master.
>>
>> Please have a look at the number of unit tests that have been pushed with
>> the merges mentioned above and the increase in code coverage reported by
>> cobertura. Both of which show hardly any changes even though mayor rewrites
>> have been introduced in the inner workings of CloudStack. I would expect to
>> see for example detailed unittests on the handling of IPv6 and numerous
>> tests to ensure that the new spring framework is up to task. Currently i
>> feel like i'm being force into releasing something that i don't trust yet.
>>
>> At collab12 one of the main themes that i was hearing all around what
>> confidence in the code base by testing. I would like the 4.1 release to be
>> a show case if that way of thinking. We have put out a very nice 4.0.0
>> release that the people i meet are very happy about. The next release
>> should be even better and inspire confidence that we are a project that is
>> able to deliver well tested and stable releases.
>>
>> Sorry for being such an ass about this, but we are all working very hard
>> on getting this release out and i really want this to be the best release
>> possible and not just a bunch of bolted-on features.
>>
>> So what do you guys think?
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> ________________________________________
>> From: Chip Childers [chip.childers@sungard.com]
>> Sent: Saturday, February 02, 2013 2:27 PM
>> To: <cl...@incubator.apache.org>
>> Subject: Re: [ACS41] 4.1 branch created
>>
>> On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
>>
>> > Does this mean features havent been merged into master will be postponed
>> to 4.2?
>> >
>>
>> Yes. That was the idea with using a time-based release planning process.
>>
>> > -Mice
>> >
>> > 2013/2/2 Alex Huang <Al...@citrix.com>:
>> >> Kelven also mentioned he had to merge a few times because code was
>> being changed in master. It is supposed to be frozen until this message
>> from Chip. Please respect the instructions the release manager has given
>> out. Master is now open but 4.1 is now frozen. Please respect this even
>> though you can check-in to 4.1. If we find "features" being sneaked in,
>> then it would make sense for us to lockdown 4.1, which makes bug fixing and
>> unit testing checkins a laborious process.
>> >>
>> >> --Alex
>> >>
>> >>> -----Original Message-----
>> >>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >>> Sent: Friday, February 01, 2013 5:58 PM
>> >>> To: cloudstack-dev@incubator.apache.org
>> >>> Subject: [ACS41] 4.1 branch created
>> >>>
>> >>> Hi all,
>> >>>
>> >>> Looks like Kelvin finished the merge of javelin into master, so I went
>> >>> ahead and branched master for the 4.1 release (after mistakenly doing
>> >>> the same for 4.2... jumping the gun by a few months ;-) )
>> >>>
>> >>> This isn't a "locked down" branch right now, but I'd ask committers to
>> >>> respect the feature and improvement freeze in that branch. Bug fixes,
>> >>> doc updates and other release stabilization activities are obviously
>> >>> expected. Committers should feel free to commit directly into that
>> >>> branch until we hit the code freeze date).
>> >>>
>> >>> For non-commiter contributors, it might be best to actually send in
>> >>> patches that have been built against the 4.1 branch. Committers
>> >>> taking these fixes should also consider applying them to master. If
>> >>> there are conflicts in master (which may happen, as there were a
>> >>> couple of code-base refactoring activities, like switching packages
>> >>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
>> >>> anyway, and inform the submitter that the patch has conflicts with
>> >>> master to get that sorted out (or you can fix it yourself).
>> >>>
>> >>> Shout if you have questions / concerns / flames.
>> >>>
>> >>> -chip
>> >
>>
Re: [ACS41] 4.1 branch created
Posted by Marcus Sorensen <sh...@gmail.com>.
Ok, I am perhaps confused because your comments about going through a
release manager I thought were related to the code freeze stage, not
feature freeze. Chip mentioned something about committers still being
free to make changes in 4.1. So perhaps we should clear that up first.
I'm not at all against pushing back, I haven't really formed an
opinion yet. I would like to hear what specifically would be
accomplished in that week or so if we did push back. We would need to
formulate some solid set of requirements that needed to be worked on,
a specific set of tests or something to avoid sounding like we're just
saying "take a week to make it better". I would suspect that the
timeline keeps things close enough that people could work in master
and pull into 4.1 over the next week or two, beyond that it does
probably make sense to cancel the branch, but again that depends on my
previous paragraph.
On Sun, Feb 3, 2013 at 12:37 AM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> Hey Marcus,
>
> We do have another month or soto fix things. My main worry is the amount of things that we still have to fix. The current consensus is that we have a release manager who does the cherry picking of fixes from master to the branch. If we have sizable number of fixes this might quickly become a bottle neck and unreasonably burden the poor guy assigned to the job (remember that its a volunteer run project). If we are able to work directly on the 4.1 branch we run the risk that 4.1 and master diverge to a point where they are increasingly difficult to realign and we get the same issues as with the javelin merge when we finish up the 4.1 release and get in shape for the 4.2 release.
>
> Normally i would be al for sticking to the process, but in this particular case we have several large features (and in the case of javelin radical architecture changes) pushed in at the very last moment possible. Combined with the poor shape of testing at the moment this calls for extra caution. This is going to be the 4.1 release, in my experience a lot of enterprise folks will hold off on .0 release and wait for .1 releases before the decide to upgrade or not. It's also our second release and folks might be waiting for that as well, not really trusting our first release yet. So i'm really aiming for this release to be the highest quality possible, i personally find this more important than sticking to the plan (at this time). And as you mentioned, the plan actually calls for large features to be merged at the beginning of the cycle, not at the end in a rush.
>
> Cheers,
>
> Hugo
>
> ________________________________________
> From: Marcus Sorensen [shadowsor@gmail.com]
> Sent: Sunday, February 03, 2013 8:23 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [ACS41] 4.1 branch created
>
> I understand the reservations as well, and I think everyone has reached the
> consensus that we should both include better test coverage and reserve
> large changes for the beginning of the dev cycle. But my impression was
> that this was just a feature freeze, and we really have another few months
> to harden things.
>
> I'm not sure it makes sense to hold off on the cut, as if we do, I think
> we'd be pushing people off from merging features to master (or risk
> continuously pushing out), and we can just address the things anyway and
> pull them into the 4.1 branch without interrupting development. I wasn't
> under the impression that the 4.1 branch would be hard to work on, just
> that we shouldn't be adding features.
>
> Are you thinking there should be a regular moratorium or something similar
> just before the cut, so that the quality of the features as a whole can be
> evaluated, or are you just concerned that the last minute features didn't
> get proper review? I think that as long as there's a time-based release
> were going to have features rushed, we either need to be OK with it and
> allow for time and ability to fix it afterward, or have some very stringent
> quality control prior to merge. We can maybe start with the former and work
> toward the latter.
> On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
> wrote:
>
>> Heya all,
>>
>> I find it way too early to cut a 4.1 release branch. I now that this is
>> what we agreed to do, but the way we are going at it doesn't sit right with
>> me. The simple fact that we have some mayor code changes forced into master
>> just are the freeze (javelin, ucs and ipv6) and immediately create a
>> release branch isn't the way to go if we want a stable release. There are
>> numerous issues with the current state of master and hence the 4.1 branch
>> like regression bugs in the maven system that have been introduced by
>> merging in old maven code with Javelin.
>>
>> I personally don't feel we are in shape yet to make the current state of
>> master into a release worthy branch as it would seriously impair the
>> ability of people to go in and fix stuff as we have to deal with a release
>> manager before patches are going into 4.1 branch.
>>
>> In fact i feel so strong about it that i'm half a mind to start a vote to
>> remove current 4.1 branch and set the next date to branch of from to a week
>> from now. I don't feel confident that the current state of the branch will
>> result in a stable release without some serious work going into it and that
>> should happen on master.
>>
>> Please have a look at the number of unit tests that have been pushed with
>> the merges mentioned above and the increase in code coverage reported by
>> cobertura. Both of which show hardly any changes even though mayor rewrites
>> have been introduced in the inner workings of CloudStack. I would expect to
>> see for example detailed unittests on the handling of IPv6 and numerous
>> tests to ensure that the new spring framework is up to task. Currently i
>> feel like i'm being force into releasing something that i don't trust yet.
>>
>> At collab12 one of the main themes that i was hearing all around what
>> confidence in the code base by testing. I would like the 4.1 release to be
>> a show case if that way of thinking. We have put out a very nice 4.0.0
>> release that the people i meet are very happy about. The next release
>> should be even better and inspire confidence that we are a project that is
>> able to deliver well tested and stable releases.
>>
>> Sorry for being such an ass about this, but we are all working very hard
>> on getting this release out and i really want this to be the best release
>> possible and not just a bunch of bolted-on features.
>>
>> So what do you guys think?
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> ________________________________________
>> From: Chip Childers [chip.childers@sungard.com]
>> Sent: Saturday, February 02, 2013 2:27 PM
>> To: <cl...@incubator.apache.org>
>> Subject: Re: [ACS41] 4.1 branch created
>>
>> On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
>>
>> > Does this mean features havent been merged into master will be postponed
>> to 4.2?
>> >
>>
>> Yes. That was the idea with using a time-based release planning process.
>>
>> > -Mice
>> >
>> > 2013/2/2 Alex Huang <Al...@citrix.com>:
>> >> Kelven also mentioned he had to merge a few times because code was
>> being changed in master. It is supposed to be frozen until this message
>> from Chip. Please respect the instructions the release manager has given
>> out. Master is now open but 4.1 is now frozen. Please respect this even
>> though you can check-in to 4.1. If we find "features" being sneaked in,
>> then it would make sense for us to lockdown 4.1, which makes bug fixing and
>> unit testing checkins a laborious process.
>> >>
>> >> --Alex
>> >>
>> >>> -----Original Message-----
>> >>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >>> Sent: Friday, February 01, 2013 5:58 PM
>> >>> To: cloudstack-dev@incubator.apache.org
>> >>> Subject: [ACS41] 4.1 branch created
>> >>>
>> >>> Hi all,
>> >>>
>> >>> Looks like Kelvin finished the merge of javelin into master, so I went
>> >>> ahead and branched master for the 4.1 release (after mistakenly doing
>> >>> the same for 4.2... jumping the gun by a few months ;-) )
>> >>>
>> >>> This isn't a "locked down" branch right now, but I'd ask committers to
>> >>> respect the feature and improvement freeze in that branch. Bug fixes,
>> >>> doc updates and other release stabilization activities are obviously
>> >>> expected. Committers should feel free to commit directly into that
>> >>> branch until we hit the code freeze date).
>> >>>
>> >>> For non-commiter contributors, it might be best to actually send in
>> >>> patches that have been built against the 4.1 branch. Committers
>> >>> taking these fixes should also consider applying them to master. If
>> >>> there are conflicts in master (which may happen, as there were a
>> >>> couple of code-base refactoring activities, like switching packages
>> >>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
>> >>> anyway, and inform the submitter that the patch has conflicts with
>> >>> master to get that sorted out (or you can fix it yourself).
>> >>>
>> >>> Shout if you have questions / concerns / flames.
>> >>>
>> >>> -chip
>> >
>>
RE: [ACS41] 4.1 branch created
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey Marcus,
We do have another month or soto fix things. My main worry is the amount of things that we still have to fix. The current consensus is that we have a release manager who does the cherry picking of fixes from master to the branch. If we have sizable number of fixes this might quickly become a bottle neck and unreasonably burden the poor guy assigned to the job (remember that its a volunteer run project). If we are able to work directly on the 4.1 branch we run the risk that 4.1 and master diverge to a point where they are increasingly difficult to realign and we get the same issues as with the javelin merge when we finish up the 4.1 release and get in shape for the 4.2 release.
Normally i would be al for sticking to the process, but in this particular case we have several large features (and in the case of javelin radical architecture changes) pushed in at the very last moment possible. Combined with the poor shape of testing at the moment this calls for extra caution. This is going to be the 4.1 release, in my experience a lot of enterprise folks will hold off on .0 release and wait for .1 releases before the decide to upgrade or not. It's also our second release and folks might be waiting for that as well, not really trusting our first release yet. So i'm really aiming for this release to be the highest quality possible, i personally find this more important than sticking to the plan (at this time). And as you mentioned, the plan actually calls for large features to be merged at the beginning of the cycle, not at the end in a rush.
Cheers,
Hugo
________________________________________
From: Marcus Sorensen [shadowsor@gmail.com]
Sent: Sunday, February 03, 2013 8:23 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [ACS41] 4.1 branch created
I understand the reservations as well, and I think everyone has reached the
consensus that we should both include better test coverage and reserve
large changes for the beginning of the dev cycle. But my impression was
that this was just a feature freeze, and we really have another few months
to harden things.
I'm not sure it makes sense to hold off on the cut, as if we do, I think
we'd be pushing people off from merging features to master (or risk
continuously pushing out), and we can just address the things anyway and
pull them into the 4.1 branch without interrupting development. I wasn't
under the impression that the 4.1 branch would be hard to work on, just
that we shouldn't be adding features.
Are you thinking there should be a regular moratorium or something similar
just before the cut, so that the quality of the features as a whole can be
evaluated, or are you just concerned that the last minute features didn't
get proper review? I think that as long as there's a time-based release
were going to have features rushed, we either need to be OK with it and
allow for time and ability to fix it afterward, or have some very stringent
quality control prior to merge. We can maybe start with the former and work
toward the latter.
On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
wrote:
> Heya all,
>
> I find it way too early to cut a 4.1 release branch. I now that this is
> what we agreed to do, but the way we are going at it doesn't sit right with
> me. The simple fact that we have some mayor code changes forced into master
> just are the freeze (javelin, ucs and ipv6) and immediately create a
> release branch isn't the way to go if we want a stable release. There are
> numerous issues with the current state of master and hence the 4.1 branch
> like regression bugs in the maven system that have been introduced by
> merging in old maven code with Javelin.
>
> I personally don't feel we are in shape yet to make the current state of
> master into a release worthy branch as it would seriously impair the
> ability of people to go in and fix stuff as we have to deal with a release
> manager before patches are going into 4.1 branch.
>
> In fact i feel so strong about it that i'm half a mind to start a vote to
> remove current 4.1 branch and set the next date to branch of from to a week
> from now. I don't feel confident that the current state of the branch will
> result in a stable release without some serious work going into it and that
> should happen on master.
>
> Please have a look at the number of unit tests that have been pushed with
> the merges mentioned above and the increase in code coverage reported by
> cobertura. Both of which show hardly any changes even though mayor rewrites
> have been introduced in the inner workings of CloudStack. I would expect to
> see for example detailed unittests on the handling of IPv6 and numerous
> tests to ensure that the new spring framework is up to task. Currently i
> feel like i'm being force into releasing something that i don't trust yet.
>
> At collab12 one of the main themes that i was hearing all around what
> confidence in the code base by testing. I would like the 4.1 release to be
> a show case if that way of thinking. We have put out a very nice 4.0.0
> release that the people i meet are very happy about. The next release
> should be even better and inspire confidence that we are a project that is
> able to deliver well tested and stable releases.
>
> Sorry for being such an ass about this, but we are all working very hard
> on getting this release out and i really want this to be the best release
> possible and not just a bunch of bolted-on features.
>
> So what do you guys think?
>
> Cheers,
>
> Hugo
>
>
> ________________________________________
> From: Chip Childers [chip.childers@sungard.com]
> Sent: Saturday, February 02, 2013 2:27 PM
> To: <cl...@incubator.apache.org>
> Subject: Re: [ACS41] 4.1 branch created
>
> On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
>
> > Does this mean features havent been merged into master will be postponed
> to 4.2?
> >
>
> Yes. That was the idea with using a time-based release planning process.
>
> > -Mice
> >
> > 2013/2/2 Alex Huang <Al...@citrix.com>:
> >> Kelven also mentioned he had to merge a few times because code was
> being changed in master. It is supposed to be frozen until this message
> from Chip. Please respect the instructions the release manager has given
> out. Master is now open but 4.1 is now frozen. Please respect this even
> though you can check-in to 4.1. If we find "features" being sneaked in,
> then it would make sense for us to lockdown 4.1, which makes bug fixing and
> unit testing checkins a laborious process.
> >>
> >> --Alex
> >>
> >>> -----Original Message-----
> >>> From: Chip Childers [mailto:chip.childers@sungard.com]
> >>> Sent: Friday, February 01, 2013 5:58 PM
> >>> To: cloudstack-dev@incubator.apache.org
> >>> Subject: [ACS41] 4.1 branch created
> >>>
> >>> Hi all,
> >>>
> >>> Looks like Kelvin finished the merge of javelin into master, so I went
> >>> ahead and branched master for the 4.1 release (after mistakenly doing
> >>> the same for 4.2... jumping the gun by a few months ;-) )
> >>>
> >>> This isn't a "locked down" branch right now, but I'd ask committers to
> >>> respect the feature and improvement freeze in that branch. Bug fixes,
> >>> doc updates and other release stabilization activities are obviously
> >>> expected. Committers should feel free to commit directly into that
> >>> branch until we hit the code freeze date).
> >>>
> >>> For non-commiter contributors, it might be best to actually send in
> >>> patches that have been built against the 4.1 branch. Committers
> >>> taking these fixes should also consider applying them to master. If
> >>> there are conflicts in master (which may happen, as there were a
> >>> couple of code-base refactoring activities, like switching packages
> >>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
> >>> anyway, and inform the submitter that the patch has conflicts with
> >>> master to get that sorted out (or you can fix it yourself).
> >>>
> >>> Shout if you have questions / concerns / flames.
> >>>
> >>> -chip
> >
>
RE: [ACS41] 4.1 branch created
Posted by Devdeep Singh <de...@citrix.com>.
+1 for gerrit.
Regards,
Devdeep
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, February 04, 2013 12:20 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [ACS41] 4.1 branch created
>
> On Sun, Feb 3, 2013 at 2:23 AM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> > Are you thinking there should be a regular moratorium or something
> > similar just before the cut, so that the quality of the features as a
> > whole can be evaluated, or are you just concerned that the last minute
> > features didn't get proper review? I think that as long as there's a
> > time-based release were going to have features rushed, we either need
> > to be OK with it and allow for time and ability to fix it afterward,
> > or have some very stringent quality control prior to merge. We can
> > maybe start with the former and work toward the latter.
>
> That's exactly right. We're either going to do time-based release schedules,
> or we're not. And if we are doing time-based releases we need to be
> concerned about the quality of commits coming into master.
> Anyone want to get gerrit up and running? I'd be more than happy if we had a
> strict review process for ALL commits coming into master, regardless of
> commit access permissions.
SV: [ACS41] 4.1 branch created
Posted by Alex Mathiasen <am...@mira.dk>.
Dear Cloudstack developers,
I have a scenario with a management-server, 3 host servers and some NFS storage.
However I am experiencing some issues:
I already have a zone configured working without issues. (Advanced)
Management-network: x.x.6.10-x.x.6.60 - Guest network: x.x.6.100-x.x.6.200
Adding a new zone (Basic) won't work.
Management-network: x.x.6.61-x.x.6.91 - Guest network: x.x.6.201-x.x.6.254
The zone is added and enabled without issues - And system VM's are added and booted also without issues.
However it seems my system Vm's can't be accessed, or access the network. I really can't find a solution to this problem. Any suggestions?
This is what happends when I try to access console in the zone that doesn't work:
==> /var/log/cloud/management/management-server.log <==
2013-02-05 14:43:18,045 DEBUG [agent.transport.Request] (catalina-exec-5:null) Seq 33-115998788: Sending { Cmd , MgmtId: 60908668245, via: 33, Ver: v1, Flags: 100011, [{"GetVncPortCommand":{"id":302,"name":"s-302-VM","wait":0}}] }
2013-02-05 14:43:18,100 DEBUG [agent.transport.Request] (AgentManager-Handler-2:null) Seq 33-115998788: Processing: { Ans: , MgmtId: 60908668245, via: 33, Ver: v1, Flags: 10, [{"GetVncPortAnswer":{"address":"x.x.6.4","port":5901,"result":true,"wait":0}}] }
2013-02-05 14:43:18,100 DEBUG [agent.transport.Request] (catalina-exec-5:null) Seq 33-115998788: Received: { Ans: , MgmtId: 60908668245, via: 33, Ver: v1, Flags: 10, { GetVncPortAnswer } }
2013-02-05 14:43:18,100 DEBUG [cloud.servlet.ConsoleProxyServlet] (catalina-exec-5:null) Port info x.x.6.4
2013-02-05 14:43:18,100 INFO [cloud.servlet.ConsoleProxyServlet] (catalina-exec-5:null) Parse host info returned from executing GetVNCPortCommand. host info: x.x.6.4
2013-02-05 14:43:18,101 DEBUG [cloud.servlet.ConsoleProxyServlet] (catalina-exec-5:null) Compose console url: https://x-x-6-233.realhostip.com/ajax?token=BRt45NJ1f1BNErxhr8OtxNCOSqGTzUPfNIFPGjeWm9bFhBXVQ0BfMjY4LxIS5shdfxCoRC3FV-ZluhK0E-TCFXR6XmnHPK52Vm0mQe7W08cnQjGMz-eZSjE-_ynBCoKJs6ix_3Gk5qbXMJnSJF9XyYaM0GCeQxJh9AZDaZ1QLLrlzc26O7Fpgxqt2yCuim6zmE3NLuqMWima4Pj509yT3zrp1MuD4INK7c_exKtGvXNIoXlxa2H6fO531QB4jjZeDK-taNJCzjs
2013-02-05 14:43:18,102 DEBUG [cloud.servlet.ConsoleProxyServlet] (catalina-exec-5:null) the console url is :: <html><title>s-302-VM</title><frameset><frame src="https://x-x-6-233.realhostip.com/ajax?token=BRt45NJ1f1BNErxhr8OtxNCOSqGTzUPfNIFPGjeWm9bFhBXVQ0BfMjY4LxIS5shdfxCoRC3FV-ZluhK0E-TCFXR6XmnHPK52Vm0mQe7W08cnQjGMz-eZSjE-_ynBCoKJs6ix_3Gk5qbXMJnSJF9XyYaM0GCeQxJh9AZDaZ1QLLrlzc26O7Fpgxqt2yCuim6zmE3NLuqMWima4Pj509yT3zrp1MuD4INK7c_exKtGvXNIoXlxa2H6fO531QB4jjZeDK-taNJCzjs"></frame></frameset></html
This is what happends when I try to access console in a zone that works:
2013-02-05 14:43:45,305 DEBUG [cloud.server.StatsCollector] (StatsCollector-3:null) VmStatsCollector is running...
2013-02-05 14:43:45,350 DEBUG [agent.transport.Request] (StatsCollector-3:null) Seq 1-1969554088: Received: { Ans: , MgmtId: 60908668245, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-02-05 14:43:45,378 DEBUG [agent.transport.Request] (StatsCollector-3:null) Seq 4-591855939: Received: { Ans: , MgmtId: 60908668245, via: 4, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-02-05 14:43:45,858 DEBUG [agent.transport.Request] (catalina-exec-8:null) Seq 4-591855940: Sending { Cmd , MgmtId: 60908668245, via: 4, Ver: v1, Flags: 100011, [{"GetVncPortCommand":{"id":2,"name":"v-2-VM","wait":0}}] }
2013-02-05 14:43:45,906 DEBUG [agent.transport.Request] (AgentManager-Handler-14:null) Seq 4-591855940: Processing: { Ans: , MgmtId: 60908668245, via: 4, Ver: v1, Flags: 10, [{"GetVncPortAnswer":{"address":"x.x.6.3","port":5900,"result":true,"wait":0}}] }
2013-02-05 14:43:45,906 DEBUG [agent.transport.Request] (catalina-exec-8:null) Seq 4-591855940: Received: { Ans: , MgmtId: 60908668245, via: 4, Ver: v1, Flags: 10, { GetVncPortAnswer } }
2013-02-05 14:43:45,906 DEBUG [cloud.servlet.ConsoleProxyServlet] (catalina-exec-8:null) Port info x.x.6.3
2013-02-05 14:43:45,906 INFO [cloud.servlet.ConsoleProxyServlet] (catalina-exec-8:null) Parse host info returned from executing GetVNCPortCommand. host info: x.x.6.3
2013-02-05 14:43:45,910 DEBUG [cloud.servlet.ConsoleProxyServlet] (catalina-exec-8:null) Compose console url: https://x-x-6-185.realhostip.com/ajax?token=BRt45NJ1f1BNErxhr8OtxNCOSqGTzUPfbSNuIHwVBv7FhBXVQ0BfMjY4LxIS5shdYR8T0FSdzDxluhK0E-TCFXR6XmnHPK52vKovhOpX6xzshqTgDmbYDhZD67ILCLvXm9oDC6m1lMbJceDmbVtamTnl_nKvmJqgCoGXyG2y4TxtHa4hc-JgvIpA1wZtHsDihmH1P_Eo5EmXljmwCicfyL57cF4-7eZZGqGP5JO4hUct8UWBXF3UWBO7DhuQPwbp
2013-02-05 14:43:45,910 DEBUG [cloud.servlet.ConsoleProxyServlet] (catalina-exec-8:null) the console url is :: <html><title>v-2-VM</title><frameset><frame src="https://x-x-6-185.realhostip.com/ajax?token=BRt45NJ1f1BNErxhr8OtxNCOSqGTzUPfbSNuIHwVBv7FhBXVQ0BfMjY4LxIS5shdYR8T0FSdzDxluhK0E-TCFXR6XmnHPK52vKovhOpX6xzshqTgDmbYDhZD67ILCLvXm9oDC6m1lMbJceDmbVtamTnl_nKvmJqgCoGXyG2y4TxtHa4hc-JgvIpA1wZtHsDihmH1P_Eo5EmXljmwCicfyL57cF4-7eZZGqGP5JO4hUct8UWBXF3UWBO7DhuQPwbp"></frame></frameset></html>
2013-02-05 14:43:46,352 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-8:null) SeqA 3-8968: Processing Seq 3-8968: { Cmd , MgmtId: -1, via: 3, Ver: v1, Flags: 11, [{"ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n \"connections\": [\n {\n \"id\": 150,\n \"clientInfo\": \"\",\n \"host\": \"x.x.6.3\",\n \"port\": 5900,\n \"tag\": \"7af06d9c-ec0d-47a3-ab9b-ccf908ea16e1\",\n \"createTime\": 1360071852417,\n \"lastUsedTime\": 1360071852417\n }\n ]\n}","wait":0}}] }
2013-02-05 14:43:46,400 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-8:null) SeqA 3-8968: Sending Seq 3-8968: { Ans: , MgmtId: 60908668245, via: 3, Ver: v1, Flags: 100010, [{"AgentControlAnswer":{"result":true,"wait":0}}] }
Med venlig hilsen / Best regards
Alex Mathiasen
Systemadministrator
am@mira.dk
Tel. (+45) 96101515
--------------------------------------------------
Mira InternetSolutions ApS
http://www.mira.dk/
Tel. (+45) 9610 1510
Fax. (+45) 9610 1511
--------------------------------------------------
Confidentiality statement
The information in this e-mail and any attachments is confidential.
It is intended for the specified recipient(s) only. If you are not one of the specified recipients please notify the sender immediately.
Distribution of an incorrectly received message may be unlawful.
RE: [ACS41] 4.1 branch created
Posted by Saksham Srivastava <sa...@citrix.com>.
+1 for Gerrit.
________________________________________
From: Sanjay Tripathi [sanjay.tripathi@citrix.com]
Sent: Tuesday, February 05, 2013 8:23 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [ACS41] 4.1 branch created
+1 for Gerrit.
> -----Original Message-----
> From: Sateesh Chodapuneedi [mailto:sateesh.chodapuneedi@citrix.com]
> Sent: Monday, February 04, 2013 11:43 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [ACS41] 4.1 branch created
>
> +1 for review process through Gerrit
>
> > -----Original Message-----
> > From: Chip Childers [mailto:chip.childers@sungard.com]
> > Sent: 04 February 2013 00:20
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: [ACS41] 4.1 branch created
> >
> > On Sun, Feb 3, 2013 at 2:23 AM, Marcus Sorensen
> <sh...@gmail.com>
> > wrote:
> > > Are you thinking there should be a regular moratorium or something
> > > similar just before the cut, so that the quality of the features as
> > > a whole can be evaluated, or are you just concerned that the last
> > > minute features didn't get proper review? I think that as long as
> > > there's a time-based release were going to have features rushed, we
> > > either need to be OK with it and allow for time and ability to fix
> > > it afterward, or have some very stringent quality control prior to
> > > merge. We can maybe start with the former and work toward the latter.
> >
> > That's exactly right. We're either going to do time-based release
> > schedules, or we're not. And if we are doing time-based releases we
> > need to be concerned about the quality of commits coming into master.
> > Anyone want to get gerrit up and running? I'd be more than happy if
> > we had a strict review process for ALL commits coming into master,
> > regardless of commit access permissions.
RE: [ACS41] 4.1 branch created
Posted by Sanjay Tripathi <sa...@citrix.com>.
+1 for Gerrit.
> -----Original Message-----
> From: Sateesh Chodapuneedi [mailto:sateesh.chodapuneedi@citrix.com]
> Sent: Monday, February 04, 2013 11:43 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [ACS41] 4.1 branch created
>
> +1 for review process through Gerrit
>
> > -----Original Message-----
> > From: Chip Childers [mailto:chip.childers@sungard.com]
> > Sent: 04 February 2013 00:20
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: [ACS41] 4.1 branch created
> >
> > On Sun, Feb 3, 2013 at 2:23 AM, Marcus Sorensen
> <sh...@gmail.com>
> > wrote:
> > > Are you thinking there should be a regular moratorium or something
> > > similar just before the cut, so that the quality of the features as
> > > a whole can be evaluated, or are you just concerned that the last
> > > minute features didn't get proper review? I think that as long as
> > > there's a time-based release were going to have features rushed, we
> > > either need to be OK with it and allow for time and ability to fix
> > > it afterward, or have some very stringent quality control prior to
> > > merge. We can maybe start with the former and work toward the latter.
> >
> > That's exactly right. We're either going to do time-based release
> > schedules, or we're not. And if we are doing time-based releases we
> > need to be concerned about the quality of commits coming into master.
> > Anyone want to get gerrit up and running? I'd be more than happy if
> > we had a strict review process for ALL commits coming into master,
> > regardless of commit access permissions.
RE: [ACS41] 4.1 branch created
Posted by Sateesh Chodapuneedi <sa...@citrix.com>.
+1 for review process through Gerrit
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: 04 February 2013 00:20
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [ACS41] 4.1 branch created
>
> On Sun, Feb 3, 2013 at 2:23 AM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> > Are you thinking there should be a regular moratorium or something
> > similar just before the cut, so that the quality of the features as a
> > whole can be evaluated, or are you just concerned that the last minute
> > features didn't get proper review? I think that as long as there's a
> > time-based release were going to have features rushed, we either need
> > to be OK with it and allow for time and ability to fix it afterward,
> > or have some very stringent quality control prior to merge. We can
> > maybe start with the former and work toward the latter.
>
> That's exactly right. We're either going to do time-based release schedules,
> or we're not. And if we are doing time-based releases we need to be
> concerned about the quality of commits coming into master.
> Anyone want to get gerrit up and running? I'd be more than happy if we had
> a strict review process for ALL commits coming into master, regardless of
> commit access permissions.
Re: [ACS41] 4.1 branch created
Posted by Sheng Yang <sh...@yasker.org>.
On Sun, Feb 3, 2013 at 5:03 PM, Rohit Yadav <bh...@apache.org> wrote:
> On Mon, Feb 4, 2013 at 5:29 AM, David Nalley <da...@gnsa.us> wrote:
> ...
>>
>>
>> I've had some folks express interesting in setting up Gerrit for code reviews.
>> That said - it's not like we can't review code that is already
>> committed - we get commit mails after all. Gerrit just helps automate
>> some of that.
>
> David, sure we've a commits ML does not mean everyone is on it,
> besides searching, commenting is not smooth. It's not a question of
> "want" I think, we need a platform where we can discuss and share
> code, i.e. a code reviewing platform. I researched few of the
> opensource ones, I really want to setup phabricator (our own jzb's
> review [1]), or gerrit or some code reviewing platform and enforce
> that every commit that goes in, goes with some review. If ASF infra
> can give me a VM, I can setup one that can be used by any project and
> not just CloudStack (guide me setup I will). And if we have that, I
> want us to enforce that no one commits on master (and select version
> branches) without a code review so that at least one other person in
> the community has carefully seen every single change. Sure, flame me
> saying that it's an opensource project and everyone's contributing in
> their free time so this won't work (yeah right like it's working so
> well now).
>
> [1] a review by our very own jzb;
> http://readwrite.com/2011/09/28/a-look-at-phabricator-facebook
>
> Regards.
> PS. Let me too rant and explain my view of the world (my works my own,
> lean more on semantics and not syntax); As an engineer who wants to
> join the hacker club, I want to work on best stuff, with best people
> and conquer those problem, puzzles with the best tools, best code,
> best engineering practices. Sure I may have made few of you smile or
> laugh, I think working with CloudStack's large codebase with diagonal
> dependencies and a broad spectrum of computer science domains and
> connecting dots between these components, layers and how this big
> monolithic monster works is interesting enough. In last 6 months, I'm
> sick of the non-issues, see a feature marathon "the quantity", I just
> want us to focus on quality now, let's just aim next releases totally
> on "the quality" and fix our coding practices, so I think we "need" a
> code reviewing platform, gerrit, phabricator, reviewing on ML. I hate
> the code bureaucracy,
Talking about better discussion environment, I still didn't see any
change to our mailing list policy, since we've agreed to change to
LKML style(allow TO/CC shows to involve people in the thread).
Jira ticket is still open without progress:
https://issues.apache.org/jira/browse/CLOUDSTACK-1059
--Sheng
Re: [ACS41] 4.1 branch created
Posted by Rohit Yadav <bh...@apache.org>.
On Mon, Feb 4, 2013 at 5:29 AM, David Nalley <da...@gnsa.us> wrote:
...
>
>
> I've had some folks express interesting in setting up Gerrit for code reviews.
> That said - it's not like we can't review code that is already
> committed - we get commit mails after all. Gerrit just helps automate
> some of that.
David, sure we've a commits ML does not mean everyone is on it,
besides searching, commenting is not smooth. It's not a question of
"want" I think, we need a platform where we can discuss and share
code, i.e. a code reviewing platform. I researched few of the
opensource ones, I really want to setup phabricator (our own jzb's
review [1]), or gerrit or some code reviewing platform and enforce
that every commit that goes in, goes with some review. If ASF infra
can give me a VM, I can setup one that can be used by any project and
not just CloudStack (guide me setup I will). And if we have that, I
want us to enforce that no one commits on master (and select version
branches) without a code review so that at least one other person in
the community has carefully seen every single change. Sure, flame me
saying that it's an opensource project and everyone's contributing in
their free time so this won't work (yeah right like it's working so
well now).
[1] a review by our very own jzb;
http://readwrite.com/2011/09/28/a-look-at-phabricator-facebook
Regards.
PS. Let me too rant and explain my view of the world (my works my own,
lean more on semantics and not syntax); As an engineer who wants to
join the hacker club, I want to work on best stuff, with best people
and conquer those problem, puzzles with the best tools, best code,
best engineering practices. Sure I may have made few of you smile or
laugh, I think working with CloudStack's large codebase with diagonal
dependencies and a broad spectrum of computer science domains and
connecting dots between these components, layers and how this big
monolithic monster works is interesting enough. In last 6 months, I'm
sick of the non-issues, see a feature marathon "the quantity", I just
want us to focus on quality now, let's just aim next releases totally
on "the quality" and fix our coding practices, so I think we "need" a
code reviewing platform, gerrit, phabricator, reviewing on ML. I hate
the code bureaucracy,
Re: [ACS41] 4.1 branch created
Posted by David Nalley <da...@gnsa.us>.
On Sun, Feb 3, 2013 at 1:50 PM, Chip Childers <ch...@sungard.com> wrote:
> On Sun, Feb 3, 2013 at 2:23 AM, Marcus Sorensen <sh...@gmail.com> wrote:
>> Are you thinking there should be a regular moratorium or something similar
>> just before the cut, so that the quality of the features as a whole can be
>> evaluated, or are you just concerned that the last minute features didn't
>> get proper review? I think that as long as there's a time-based release
>> were going to have features rushed, we either need to be OK with it and
>> allow for time and ability to fix it afterward, or have some very stringent
>> quality control prior to merge. We can maybe start with the former and work
>> toward the latter.
>
> That's exactly right. We're either going to do time-based release
> schedules, or we're not. And if we are doing time-based releases we
> need to be concerned about the quality of commits coming into master.
> Anyone want to get gerrit up and running? I'd be more than happy if
> we had a strict review process for ALL commits coming into master,
> regardless of commit access permissions.
I've had some folks express interesting in setting up Gerrit for code reviews.
That said - it's not like we can't review code that is already
committed - we get commit mails after all. Gerrit just helps automate
some of that.
--David
Re: [ACS41] 4.1 branch created
Posted by Chip Childers <ch...@sungard.com>.
On Sun, Feb 3, 2013 at 2:23 AM, Marcus Sorensen <sh...@gmail.com> wrote:
> Are you thinking there should be a regular moratorium or something similar
> just before the cut, so that the quality of the features as a whole can be
> evaluated, or are you just concerned that the last minute features didn't
> get proper review? I think that as long as there's a time-based release
> were going to have features rushed, we either need to be OK with it and
> allow for time and ability to fix it afterward, or have some very stringent
> quality control prior to merge. We can maybe start with the former and work
> toward the latter.
That's exactly right. We're either going to do time-based release
schedules, or we're not. And if we are doing time-based releases we
need to be concerned about the quality of commits coming into master.
Anyone want to get gerrit up and running? I'd be more than happy if
we had a strict review process for ALL commits coming into master,
regardless of commit access permissions.
RE: [ACS41] 4.1 branch created
Posted by Marcus Sorensen <sh...@gmail.com>.
I understand the reservations as well, and I think everyone has reached the
consensus that we should both include better test coverage and reserve
large changes for the beginning of the dev cycle. But my impression was
that this was just a feature freeze, and we really have another few months
to harden things.
I'm not sure it makes sense to hold off on the cut, as if we do, I think
we'd be pushing people off from merging features to master (or risk
continuously pushing out), and we can just address the things anyway and
pull them into the 4.1 branch without interrupting development. I wasn't
under the impression that the 4.1 branch would be hard to work on, just
that we shouldn't be adding features.
Are you thinking there should be a regular moratorium or something similar
just before the cut, so that the quality of the features as a whole can be
evaluated, or are you just concerned that the last minute features didn't
get proper review? I think that as long as there's a time-based release
were going to have features rushed, we either need to be OK with it and
allow for time and ability to fix it afterward, or have some very stringent
quality control prior to merge. We can maybe start with the former and work
toward the latter.
On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
wrote:
> Heya all,
>
> I find it way too early to cut a 4.1 release branch. I now that this is
> what we agreed to do, but the way we are going at it doesn't sit right with
> me. The simple fact that we have some mayor code changes forced into master
> just are the freeze (javelin, ucs and ipv6) and immediately create a
> release branch isn't the way to go if we want a stable release. There are
> numerous issues with the current state of master and hence the 4.1 branch
> like regression bugs in the maven system that have been introduced by
> merging in old maven code with Javelin.
>
> I personally don't feel we are in shape yet to make the current state of
> master into a release worthy branch as it would seriously impair the
> ability of people to go in and fix stuff as we have to deal with a release
> manager before patches are going into 4.1 branch.
>
> In fact i feel so strong about it that i'm half a mind to start a vote to
> remove current 4.1 branch and set the next date to branch of from to a week
> from now. I don't feel confident that the current state of the branch will
> result in a stable release without some serious work going into it and that
> should happen on master.
>
> Please have a look at the number of unit tests that have been pushed with
> the merges mentioned above and the increase in code coverage reported by
> cobertura. Both of which show hardly any changes even though mayor rewrites
> have been introduced in the inner workings of CloudStack. I would expect to
> see for example detailed unittests on the handling of IPv6 and numerous
> tests to ensure that the new spring framework is up to task. Currently i
> feel like i'm being force into releasing something that i don't trust yet.
>
> At collab12 one of the main themes that i was hearing all around what
> confidence in the code base by testing. I would like the 4.1 release to be
> a show case if that way of thinking. We have put out a very nice 4.0.0
> release that the people i meet are very happy about. The next release
> should be even better and inspire confidence that we are a project that is
> able to deliver well tested and stable releases.
>
> Sorry for being such an ass about this, but we are all working very hard
> on getting this release out and i really want this to be the best release
> possible and not just a bunch of bolted-on features.
>
> So what do you guys think?
>
> Cheers,
>
> Hugo
>
>
> ________________________________________
> From: Chip Childers [chip.childers@sungard.com]
> Sent: Saturday, February 02, 2013 2:27 PM
> To: <cl...@incubator.apache.org>
> Subject: Re: [ACS41] 4.1 branch created
>
> On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
>
> > Does this mean features havent been merged into master will be postponed
> to 4.2?
> >
>
> Yes. That was the idea with using a time-based release planning process.
>
> > -Mice
> >
> > 2013/2/2 Alex Huang <Al...@citrix.com>:
> >> Kelven also mentioned he had to merge a few times because code was
> being changed in master. It is supposed to be frozen until this message
> from Chip. Please respect the instructions the release manager has given
> out. Master is now open but 4.1 is now frozen. Please respect this even
> though you can check-in to 4.1. If we find "features" being sneaked in,
> then it would make sense for us to lockdown 4.1, which makes bug fixing and
> unit testing checkins a laborious process.
> >>
> >> --Alex
> >>
> >>> -----Original Message-----
> >>> From: Chip Childers [mailto:chip.childers@sungard.com]
> >>> Sent: Friday, February 01, 2013 5:58 PM
> >>> To: cloudstack-dev@incubator.apache.org
> >>> Subject: [ACS41] 4.1 branch created
> >>>
> >>> Hi all,
> >>>
> >>> Looks like Kelvin finished the merge of javelin into master, so I went
> >>> ahead and branched master for the 4.1 release (after mistakenly doing
> >>> the same for 4.2... jumping the gun by a few months ;-) )
> >>>
> >>> This isn't a "locked down" branch right now, but I'd ask committers to
> >>> respect the feature and improvement freeze in that branch. Bug fixes,
> >>> doc updates and other release stabilization activities are obviously
> >>> expected. Committers should feel free to commit directly into that
> >>> branch until we hit the code freeze date).
> >>>
> >>> For non-commiter contributors, it might be best to actually send in
> >>> patches that have been built against the 4.1 branch. Committers
> >>> taking these fixes should also consider applying them to master. If
> >>> there are conflicts in master (which may happen, as there were a
> >>> couple of code-base refactoring activities, like switching packages
> >>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
> >>> anyway, and inform the submitter that the patch has conflicts with
> >>> master to get that sorted out (or you can fix it yourself).
> >>>
> >>> Shout if you have questions / concerns / flames.
> >>>
> >>> -chip
> >
>
RE: [ACS41] 4.1 branch created
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Heya all,
I find it way too early to cut a 4.1 release branch. I now that this is what we agreed to do, but the way we are going at it doesn't sit right with me. The simple fact that we have some mayor code changes forced into master just are the freeze (javelin, ucs and ipv6) and immediately create a release branch isn't the way to go if we want a stable release. There are numerous issues with the current state of master and hence the 4.1 branch like regression bugs in the maven system that have been introduced by merging in old maven code with Javelin.
I personally don't feel we are in shape yet to make the current state of master into a release worthy branch as it would seriously impair the ability of people to go in and fix stuff as we have to deal with a release manager before patches are going into 4.1 branch.
In fact i feel so strong about it that i'm half a mind to start a vote to remove current 4.1 branch and set the next date to branch of from to a week from now. I don't feel confident that the current state of the branch will result in a stable release without some serious work going into it and that should happen on master.
Please have a look at the number of unit tests that have been pushed with the merges mentioned above and the increase in code coverage reported by cobertura. Both of which show hardly any changes even though mayor rewrites have been introduced in the inner workings of CloudStack. I would expect to see for example detailed unittests on the handling of IPv6 and numerous tests to ensure that the new spring framework is up to task. Currently i feel like i'm being force into releasing something that i don't trust yet.
At collab12 one of the main themes that i was hearing all around what confidence in the code base by testing. I would like the 4.1 release to be a show case if that way of thinking. We have put out a very nice 4.0.0 release that the people i meet are very happy about. The next release should be even better and inspire confidence that we are a project that is able to deliver well tested and stable releases.
Sorry for being such an ass about this, but we are all working very hard on getting this release out and i really want this to be the best release possible and not just a bunch of bolted-on features.
So what do you guys think?
Cheers,
Hugo
________________________________________
From: Chip Childers [chip.childers@sungard.com]
Sent: Saturday, February 02, 2013 2:27 PM
To: <cl...@incubator.apache.org>
Subject: Re: [ACS41] 4.1 branch created
On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
> Does this mean features havent been merged into master will be postponed to 4.2?
>
Yes. That was the idea with using a time-based release planning process.
> -Mice
>
> 2013/2/2 Alex Huang <Al...@citrix.com>:
>> Kelven also mentioned he had to merge a few times because code was being changed in master. It is supposed to be frozen until this message from Chip. Please respect the instructions the release manager has given out. Master is now open but 4.1 is now frozen. Please respect this even though you can check-in to 4.1. If we find "features" being sneaked in, then it would make sense for us to lockdown 4.1, which makes bug fixing and unit testing checkins a laborious process.
>>
>> --Alex
>>
>>> -----Original Message-----
>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> Sent: Friday, February 01, 2013 5:58 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: [ACS41] 4.1 branch created
>>>
>>> Hi all,
>>>
>>> Looks like Kelvin finished the merge of javelin into master, so I went
>>> ahead and branched master for the 4.1 release (after mistakenly doing
>>> the same for 4.2... jumping the gun by a few months ;-) )
>>>
>>> This isn't a "locked down" branch right now, but I'd ask committers to
>>> respect the feature and improvement freeze in that branch. Bug fixes,
>>> doc updates and other release stabilization activities are obviously
>>> expected. Committers should feel free to commit directly into that
>>> branch until we hit the code freeze date).
>>>
>>> For non-commiter contributors, it might be best to actually send in
>>> patches that have been built against the 4.1 branch. Committers
>>> taking these fixes should also consider applying them to master. If
>>> there are conflicts in master (which may happen, as there were a
>>> couple of code-base refactoring activities, like switching packages
>>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
>>> anyway, and inform the submitter that the patch has conflicts with
>>> master to get that sorted out (or you can fix it yourself).
>>>
>>> Shout if you have questions / concerns / flames.
>>>
>>> -chip
>
Re: [ACS41] 4.1 branch created
Posted by Chip Childers <ch...@sungard.com>.
On Feb 1, 2013, at 11:42 PM, Mice Xia <we...@gmail.com> wrote:
> Does this mean features havent been merged into master will be postponed to 4.2?
>
Yes. That was the idea with using a time-based release planning process.
> -Mice
>
> 2013/2/2 Alex Huang <Al...@citrix.com>:
>> Kelven also mentioned he had to merge a few times because code was being changed in master. It is supposed to be frozen until this message from Chip. Please respect the instructions the release manager has given out. Master is now open but 4.1 is now frozen. Please respect this even though you can check-in to 4.1. If we find "features" being sneaked in, then it would make sense for us to lockdown 4.1, which makes bug fixing and unit testing checkins a laborious process.
>>
>> --Alex
>>
>>> -----Original Message-----
>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> Sent: Friday, February 01, 2013 5:58 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: [ACS41] 4.1 branch created
>>>
>>> Hi all,
>>>
>>> Looks like Kelvin finished the merge of javelin into master, so I went
>>> ahead and branched master for the 4.1 release (after mistakenly doing
>>> the same for 4.2... jumping the gun by a few months ;-) )
>>>
>>> This isn't a "locked down" branch right now, but I'd ask committers to
>>> respect the feature and improvement freeze in that branch. Bug fixes,
>>> doc updates and other release stabilization activities are obviously
>>> expected. Committers should feel free to commit directly into that
>>> branch until we hit the code freeze date).
>>>
>>> For non-commiter contributors, it might be best to actually send in
>>> patches that have been built against the 4.1 branch. Committers
>>> taking these fixes should also consider applying them to master. If
>>> there are conflicts in master (which may happen, as there were a
>>> couple of code-base refactoring activities, like switching packages
>>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
>>> anyway, and inform the submitter that the patch has conflicts with
>>> master to get that sorted out (or you can fix it yourself).
>>>
>>> Shout if you have questions / concerns / flames.
>>>
>>> -chip
>
Re: [ACS41] 4.1 branch created
Posted by Mice Xia <we...@gmail.com>.
Does this mean features havent been merged into master will be postponed to 4.2?
-Mice
2013/2/2 Alex Huang <Al...@citrix.com>:
> Kelven also mentioned he had to merge a few times because code was being changed in master. It is supposed to be frozen until this message from Chip. Please respect the instructions the release manager has given out. Master is now open but 4.1 is now frozen. Please respect this even though you can check-in to 4.1. If we find "features" being sneaked in, then it would make sense for us to lockdown 4.1, which makes bug fixing and unit testing checkins a laborious process.
>
> --Alex
>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Friday, February 01, 2013 5:58 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: [ACS41] 4.1 branch created
>>
>> Hi all,
>>
>> Looks like Kelvin finished the merge of javelin into master, so I went
>> ahead and branched master for the 4.1 release (after mistakenly doing
>> the same for 4.2... jumping the gun by a few months ;-) )
>>
>> This isn't a "locked down" branch right now, but I'd ask committers to
>> respect the feature and improvement freeze in that branch. Bug fixes,
>> doc updates and other release stabilization activities are obviously
>> expected. Committers should feel free to commit directly into that
>> branch until we hit the code freeze date).
>>
>> For non-commiter contributors, it might be best to actually send in
>> patches that have been built against the 4.1 branch. Committers
>> taking these fixes should also consider applying them to master. If
>> there are conflicts in master (which may happen, as there were a
>> couple of code-base refactoring activities, like switching packages
>> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
>> anyway, and inform the submitter that the patch has conflicts with
>> master to get that sorted out (or you can fix it yourself).
>>
>> Shout if you have questions / concerns / flames.
>>
>> -chip
RE: [ACS41] 4.1 branch created
Posted by Alex Huang <Al...@citrix.com>.
Kelven also mentioned he had to merge a few times because code was being changed in master. It is supposed to be frozen until this message from Chip. Please respect the instructions the release manager has given out. Master is now open but 4.1 is now frozen. Please respect this even though you can check-in to 4.1. If we find "features" being sneaked in, then it would make sense for us to lockdown 4.1, which makes bug fixing and unit testing checkins a laborious process.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, February 01, 2013 5:58 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: [ACS41] 4.1 branch created
>
> Hi all,
>
> Looks like Kelvin finished the merge of javelin into master, so I went
> ahead and branched master for the 4.1 release (after mistakenly doing
> the same for 4.2... jumping the gun by a few months ;-) )
>
> This isn't a "locked down" branch right now, but I'd ask committers to
> respect the feature and improvement freeze in that branch. Bug fixes,
> doc updates and other release stabilization activities are obviously
> expected. Committers should feel free to commit directly into that
> branch until we hit the code freeze date).
>
> For non-commiter contributors, it might be best to actually send in
> patches that have been built against the 4.1 branch. Committers
> taking these fixes should also consider applying them to master. If
> there are conflicts in master (which may happen, as there were a
> couple of code-base refactoring activities, like switching packages
> from com.cloud to org.apache.cloudstack), apply the fix into 4.1
> anyway, and inform the submitter that the patch has conflicts with
> master to get that sorted out (or you can fix it yourself).
>
> Shout if you have questions / concerns / flames.
>
> -chip