> -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 m
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
ha
I am in agreement with my radical CloudStack brother.
On Mar 13, 2014, at 9:42 AM, David Nalley 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 list particip
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 blame
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 coded
age-----
>> 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 b
+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 b
essage-
> 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 no
--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 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 ne
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
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
wrote:
> My reasoning here is that otherwise we will just be futilely creating RCs
>
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 Thu,
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
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 if
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 features...
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 wrote:
> Its a good point. I had thought 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" wrote:
> Just a thought,
>
> Why isn't the freshly cut branch the first RC from the get go? It is
> quite sure not to
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
wrote:
> OK, so it sounds like a 3-month dev cycle for a four-month release was on
>
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 wrote:
> This was (IIRC) part of the explicit decision in how to do things. The
> thought being that if you are restricting what people can
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 cy
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
> af
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
rele
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 to
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
rel
24 matches
Mail list logo
