<div dir="ltr">So an interesting thought experiment. What if we made all changes on a stable series require an associated bug to be able to land the code there. At least as I understand "blocker" bugs on a given series, it just requires that the code proposed for landing be associated with one of the current list of blocking bugs. I'm not talking about 'master', but if you think about it, if we are backporting/changing/updating a "stable" series, it seems perfectly appropriate to require an associated bug.<div><br></div><div>Now, is there a case that certain bugs should actually block fixing other bugs. I certainly agree that bugs that don't allow us to observe the system can certainly take priority because otherwise we don't actually know whether your bug fix fixed anything.</div><div><br></div><div>Aside from that I feel like it would only be regressions. Sure there is a serious problem with 1.2x.y but if we released a 1.2x.y+1 with that same serious problem, nobody is going to be worse off.</div><div><br></div><div>I do like a plan that at any point we can cut a minor release to address something important.</div><div><br></div><div>John</div><div>=:-></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 14, 2015 at 3:43 AM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 14/07/15 09:30, Martin Packman wrote:<br>
> Thank you for responding Ian.<br>
><br>
> On 13/07/2015, Ian Booth <<a href="mailto:ian.booth@canonical.com">ian.booth@canonical.com</a>> wrote:<br>
>>><br>
>>> == Definition of blocking bugs ==<br>
>>> Master and all release branches should always be in a releasable<br>
>>> state. If a bug must be fixed for the next minor release, it is<br>
>>> considered a ‘blocker’ and will prevent all landing on that branch.<br>
>>><br>
>><br>
>> I don't agree with the above definition. There are always many bugs which<br>
>> must be fixed for the next minor release - these are assigned to the relevant<br>
>> milestones and marked high or critical.<br>
><br>
> So, my argument over this was a pretty strict interpretation of<br>
> "must". There are lots of bugs with less-than-critical severity that<br>
> get targeted at the next minor milestone, and I think that's perfect<br>
> reasonable. However, there are comparatively few bugs that could not<br>
> be deferred if, for instance, we discovered a security issue and had<br>
> to rush out a new minor release immediately.<br>
><br>
> From my perspective, blockers are things that break CI enough to<br>
> hinder our ability to do a release, or issues that if we allow into<br>
> release code will break users in unrecoverable ways. I know Aaron<br>
> prefers a much wider interpretation however.<br>
><br>
>> In the case of bug 1468653, this has been<br>
>> under investigation for 2 weeks and even though we are holding up the 1.24.3<br>
>> release for it, if it were a blocker the whole production line would have<br>
>> stalled unnecessarily.<br>
><br>
> That's an interesting bug. It seems with a lot of pain (manually<br>
> restarting things) it is actually repairable, and does involve a<br>
> pretty specific setup. I don't think I'd have added the blocker tag to<br>
> it, but that may not be the consensus.<br>
<br>
</div></div>By the definition given<br>
<span class=""><br>
"If a bug must be fixed for the next minor release, it is considered a ‘blocker’<br>
and will prevent all landing on that branch."<br>
<br>
</span>that bug and any other that we say we must include in a release would block<br>
landings. That's the bit I'm having an issue with. I think landings need to be<br>
blocked when appropriate, but not by that definition.<br>
<span class=""><br>
><br>
>> With follow on changes, the problem is<br>
>> quite isolated so landing fixes for other release critical issues should not<br>
>> be prevented.<br>
><br>
> The fact it's a somewhat isolated problem is important. What I really<br>
> want to avoid is the case where we leave say, upgrades broken as a<br>
> whole, and keep landing code. That makes it impossible to tell if<br>
> following changes also have upgrade problems, or compound the existing<br>
> issue. Likewise, if we have CI tests failing, subsequent landings make<br>
> identifying and deal with further regressions vastly more painful, and<br>
> hose our release process.<br>
><br>
<br>
</span>Depends on the changes. I think we should be pragmatic and make considered<br>
decisions. I guess that's why we have the jfdi flag.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div>