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 <shadow...@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 <daan.hoogl...@gmail.com> > wrote: > >> On Fri, Jun 19, 2015 at 8:31 PM, Marcus <shadow...@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
