The primary problem I feel is that we dont plan our releases.(I am fairly new
here and I may be wrong)
The role of the release manager starts only during the RC creation phase asking
for votes(again I maybe wrong).
I feel it should start much earlier. Everyone who is actively involved should
-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
Sent: Wednesday, March 19, 2014 4:46 AM
To: dev
Subject: Re: Release cadence
The primary problem I feel is that we dont plan our releases.(I am fairly new
here and I may be wrong) The role
I am in agreement with my radical CloudStack brother.
On Mar 13, 2014, at 9:42 AM, David Nalley da...@gnsa.us wrote:
The RC7 vote thread contained a lot of discussion around release
cadence, and I figured I'd move that to a thread that has a better
subject so there is better visibility to
I think it's a very difficult subject, because we're relying on the developers
to write tests which will show whether the code in their feature is good, and
think of every possible failure mode in order to ratify their code.
Obviously if they can think of the failure, they'll probably have
Our problem is in the test coverage of the existing code base not in
new features! As \Paul said dev will code tests they can think of.
It's the ones they didn't think of that will break stuff. But we don't
mind if new features aren't fully functional. We mind regression the
most. You can not
I wanted to add a little comment/question in general about our release
process:
Right now we typically have a one-month overlap between releases. That
being the case, if you are focusing on the current release until it is out
the door, you effectively lose a month of development for the future
The overlap is simply a byproduct of cutting the branch, I'm not sure
there's a way around it. It's a good point though, that essentially
the window is 1 month shorter than I think was intended. Better
testing will help that, however, with the point being that we
shouldn't be doing a ton of work
Yeah, if you abandon the old release as soon as a release branch is cut
for it, then you essentially have three months on the new release before
its release branch is cut and you move on to the newer release. I'm not
sure that was the intent when such a schedule was created. It means we're
On Thu, Mar 13, 2014 at 12:42:26PM -0400, David Nalley wrote:
Radical proposition:
Because we have two problems, of different nature, we are in a
difficult situation. This is a possible solution, and I'd appreciate
you reading and considering it. Feedback is welcome. I propose that
after
This was (IIRC) part of the explicit decision in how to do things. The
thought being that if you are restricting what people can do with a
release branch, people still need to be able to have a place to base
their ongoing work; and master should be that place. Some features
will take more than a
OK, so it sounds like a 3-month dev cycle for a four-month release was on
purpose.
Just curious...thanks :)
On Thu, Mar 13, 2014 at 11:31 AM, David Nalley da...@gnsa.us wrote:
This was (IIRC) part of the explicit decision in how to do things. The
thought being that if you are restricting
Just a thought,
Why isn't the freshly cut branch the first RC from the get go? It is
quite sure not to pass but it should cantain what we ant to ship
feature wise.
On Thu, Mar 13, 2014 at 6:35 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
OK, so it sounds like a 3-month dev cycle for a
Its a good point. I had thought about. Essentially we are saying that we
know the features we just merged need another few months of work.
On Mar 13, 2014 1:01 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
Just a thought,
Why isn't the freshly cut branch the first RC from the get go? It is
Thats a very good point - we are effectively saying we know the
features we merged in have potentially months worth of bugs. Though
really, our hiccups don't seem to generally be in new features, it's
old features.
On Thu, Mar 13, 2014 at 3:44 PM, Marcus shadow...@gmail.com wrote:
Its a good
I think many people (myself included) are used to performing rigorous, but
focused feature-specific testing before feature freeze, but are under the
impression that once feature freeze arrives that we are in
integration-testing mode (where our feature is tested in combination with
other
That's how i like to see it and why I asked. Is there a reason people
merge and then commit their features instead of rebasing and running a
standard set of integration tests to validate before merging. I am not
better then average on this myself but I think here is where we have
room to improve
I think we should set that as a goal for 4.5. We should treat 4.4 as
business as usual at this point and give fair warning for the next
release.
We should formally define what tested means for 4.5 and then take the
appropriate course of action from a RC point of view.
On Thu, Mar 13, 2014 at
My reasoning here is that otherwise we will just be futilely creating RCs
for 4.4 since this expectation was not clearly defined ahead of the release.
If we set expectations appropriately for 4.5, then we should expect we can
begin RC building right after Feature Freeze for that release.
On
I agree that we can't move to our end goal in on go. But I disagree
that we should go on with business as usual right now. baby steps but
never stop taking steps.
On Fri, Mar 14, 2014 at 12:20 AM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
My reasoning here is that otherwise we will just
I just think we need to call out expectations around test clearly in
advance of the next release (4.5).
Otherwise we'll be spinning up RCs for 4.4 for the next two months because
people were treating it from a test perspective like they were treating
prior releases.
On Thu, Mar 13, 2014 at 5:33
Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Thursday, March 13, 2014 4:34 PM
To: dev
Subject: Re: Release cadence
I agree that we can't move to our end goal in on go. But I disagree that we
should go on with business as usual right now. baby steps but never stop taking
]
Sent: Thursday, March 13, 2014 4:34 PM
To: dev
Subject: Re: Release cadence
I agree that we can't move to our end goal in on go. But I disagree that
we should go on with business as usual right now. baby steps but never stop
taking steps.
On Fri, Mar 14, 2014 at 12:20 AM, Mike Tutkowski
+1 Radical proposition. Setting goals and exit criteria is good so project can
be executed on time with expected level of quality. This is common for most of
SDLC processes, that teams would stick to the agreed up on quality cycles and
quality plans. Because of open source nature it might
discussion
around integration tests on 4.4 threads except find bugs and some basic
integration or sanity tests.
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Thursday, March 13, 2014 4:34 PM
To: dev
Subject: Re: Release cadence
I agree that we can't
24 matches
Mail list logo
