I think everyone's agreeing here, but maybe the wording just needs to be clarified somewhere to avoid confusion.
It sounds like "bugs which are assigned to a release do not block commits unless they are marked blockers". And blockers are determined by "we wouldn't want *anyone* to upgrade to a version with this bug in it". I agree that if a blocker is found in an earlier minor version, that upgrading to a new minor version with the same blocker doesn't make anyone any worse off. However, if we don't make it a stop-the-line, then we need some other way to ensure that the bug actually gets fixed ASAP.... otherwise it could just tag along minor after minor and not get addressed. I don't think it's unreasonable to just make such a bug a blocker, just to get it addressed ASAP, even if it is not strictly making things worse than an earlier version. On Tue, Jul 14, 2015 at 9:26 AM Aaron Bentley <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2015-07-13 07:43 PM, Ian Booth wrote: > > By the definition given > > > > "If a bug must be fixed for the next minor release, it is > > considered a ‘blocker’ and will prevent all landing on that > > branch." > > > > that bug and any other that we say we must include in a release > > would block landings. That's the bit I'm having an issue with. I > > think landings need to be blocked when appropriate, but not by that > > definition. > > Here's my rationale: > 1. We have held the principle that our trunk and stable branches > should always be releaseable. > 2. We have said we should stop-the-line when a branch becomes > unreleasable. > 3. Therefore, I have concluded that we should stop-the-line when a bug > is present that makes the branch unreleasable. > > Do you agree with 1 and 2? I think 3 simply follows from 1 and 2, but > am I wrong? > > > Depends on the changes. I think we should be pragmatic and make > > considered decisions. I guess that's why we have the jfdi flag. > > It's true that the particulars of the bug may matter in deciding > whether it should block, and that's why there's a process for > overriding the blocking tag: "Exceptions are raised to the release team." > > I think JFDI should be considered a nuclear option. If you need it, > it's good that it exists, but you shouldn't ever need it. If you > think you need it, there may be a problem with our process. > > Aaron > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVpQ3pAAoJEK84cMOcf+9h4wYIALzMezSmErdb8Gjuq89aRVU/ > CKXZGJ7fWDrsogmsBDOdNhjmtOiIkUIQiZhd3UW5+2WlC+8eix5weJGBWKIo21gx > 1hLvR6p6SnZ4zlfxV0RV0pbnfq6RqySEV9agnXzM//H/iqDwZp74ELCgR/1mLkXh > yr19JH1TVx35emqNgO6yFqFVUU6khLPM4JyJ47cjcrDip5f0qLj4gf0nRRE+rasa > uL1bJc47P0HnLr9xKxBWAioo4OMMb2RAUsgApznXWlqu/P3+TVk1eMQf7Vk1XHV8 > DbqZgMLz5iJHFpI5T6IUPeeo6BOBz+zhfse6MCqOcOavpsJTzrysMLiqrCpUYt0= > =KeYb > -----END PGP SIGNATURE----- > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
