keep stable, stable

[Marcus <sh...@gmail.com>]

I hate to bring this up, as I don't like being a curmudgeon, but
occasionally I see things like this and I wonder why we are doing it.

commit 6e3c6e82990cafdab8453ed56530dc619ba70338

Date:   Tue Jun 9 23:57:00 2015 +0200

    CLOUDSTACK-8537 refactor registerSSHKeyPair() for legibility and
testability reasons


Why are we touching 4.5 branch with anything other than known bugfixes? 4.5
is our current stable release branch, I don't think any changes to it
should be taken that aren't necessary. That includes coverity
scan/findbugs, whitespace, refactoring, etc. Just my $.02

Re: keep stable, stable

[Daan Hoogland <da...@gmail.com>]

Sorry Marcus,

This commit is one of a series of three that implement
CLOUDSTACK-8537. one is the fix. one is a refactor required to test it
and one is the test. I could have only backported the fix. It was
blocking a user from implementing convergence using terraform. So if
you are saying that I should not have backported the test for it you
got a point (this one was needed for it). Otherwise we (Rohit and I)
have been guarding these branches with exactly the policy that you
propagate.

I don't mind that you are trying press this point and agree that we
should go there. I think you could have picked a worse example to make
it in fact as this commit hits a border line.

On the other hand I also think you are wrong. cherry picking fixes
from newer release branches is not what is slowing us down.
Cherry-picking untested fixes is. This code is rather trivial but
actually in my opinion the way backporting should be done to prevent
blocking releases.

Also I think that we can not make hard on this policy. We are not
going fast enough with our releases to ask it of our users. Chicken
and egg story whcih we can circumvent by automating the testing and
using that automation. I see very little people working on fixing the
load of jenkins jobs that aren't working.

On Sat, Jun 20, 2015 at 6:49 PM, Marcus <sh...@gmail.com> wrote:
> This commit, after looking at the code for 60 seconds, looks like it
> refactors some existing code into methods to make it more testable. Perhaps
> there's more nuance than that, but the commit message doesn't point
> anything like that out to help me find it.
>
> I'm not trying to be critical of any specific commit, and this is a
> community. I don't have any special right to set the expectations on my
> own. I'm just stating my opinion, and my opinion is that once a release
> branch goes production, there should be no changes to it, save to fix
> broken functionality or security. No refactoring, no nice-to-have
> enhancements, no formatting fixes, no fixes for theoretical bugs or static
> analysis. When we release, we are in a known state, and I don't think we
> should perturb that known state unless we really, really need to.
> Otherwise, creating bugfix releases to that branch will be painful and more
> prone to regressions.
>
> In my opinion, there are two major things that keep us from turning around
> quick incremental point releases. One is this issue, the other is letting
> pre-existing bugs that aren't regressions block the vote. I will probably
> always be sensitive to these things, and if anyone takes offense to that
> I'm sorry. I realize that everyone has their own motivations, timelines,
> commitments, and pressure to get improvements into the code base, but I
> just don't think point releases are the place for most of these, and I
> don't see anyone else pushing back, so I figure I need to get the opinion
> out there, even if it's a lone one.
>
> On Fri, Jun 19, 2015 at 2:11 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>
>> On Fri, Jun 19, 2015 at 8:31 PM, Marcus <sh...@gmail.com> wrote:
>> > Why are we touching 4.5 branch with anything other than known bugfixes?
>>
>> Please don't say this is not a bug, Marcus. have a good look at what
>> it does! I had complaints on it responding counter intuitively and it
>> is in all versions.
>>
>> --
>> Daan
>>



-- 
Daan

Re: keep stable, stable

[Marcus <sh...@gmail.com>]

This commit, after looking at the code for 60 seconds, looks like it
refactors some existing code into methods to make it more testable. Perhaps
there's more nuance than that, but the commit message doesn't point
anything like that out to help me find it.

I'm not trying to be critical of any specific commit, and this is a
community. I don't have any special right to set the expectations on my
own. I'm just stating my opinion, and my opinion is that once a release
branch goes production, there should be no changes to it, save to fix
broken functionality or security. No refactoring, no nice-to-have
enhancements, no formatting fixes, no fixes for theoretical bugs or static
analysis. When we release, we are in a known state, and I don't think we
should perturb that known state unless we really, really need to.
Otherwise, creating bugfix releases to that branch will be painful and more
prone to regressions.

In my opinion, there are two major things that keep us from turning around
quick incremental point releases. One is this issue, the other is letting
pre-existing bugs that aren't regressions block the vote. I will probably
always be sensitive to these things, and if anyone takes offense to that
I'm sorry. I realize that everyone has their own motivations, timelines,
commitments, and pressure to get improvements into the code base, but I
just don't think point releases are the place for most of these, and I
don't see anyone else pushing back, so I figure I need to get the opinion
out there, even if it's a lone one.

On Fri, Jun 19, 2015 at 2:11 PM, Daan Hoogland <da...@gmail.com>
wrote:

> On Fri, Jun 19, 2015 at 8:31 PM, Marcus <sh...@gmail.com> wrote:
> > Why are we touching 4.5 branch with anything other than known bugfixes?
>
> Please don't say this is not a bug, Marcus. have a good look at what
> it does! I had complaints on it responding counter intuitively and it
> is in all versions.
>
> --
> Daan
>

Re: keep stable, stable

[Daan Hoogland <da...@gmail.com>]

On Fri, Jun 19, 2015 at 8:31 PM, Marcus <sh...@gmail.com> wrote:
> Why are we touching 4.5 branch with anything other than known bugfixes?

Please don't say this is not a bug, Marcus. have a good look at what
it does! I had complaints on it responding counter intuitively and it
is in all versions.

-- 
Daan