On 14/07/15 23:26, Aaron Bentley wrote: > 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? >
Agree with 1 and 2 (depending on the definition of unreleasable - one definition of releasable is CI passing). 3 does not follow from the definition though. A milestone may have many bugs assigned to it that we agree must be fixed before we release that milestone. simply because we think those bugs are of high importance and fit our schedule in terms of resources etc. Holding up a 20+ people development team because we have a bunch of bugs assigned to a milestone is not practical nor productive. Software has bugs. Bugs are assigned to milestones so we can plan releases. We generally agree that we want all bugs on a milestone to be fixed prior to releasing (or else why add them to that milestone). This does not (or should not IMO) make them blockers. I am happy with the process we have now. CI passing means a branch is releasable. That's our current definition (we wait for a bless before releasing). When CI breaks we stop the line to fix CI (and rollback of the revision that just landed to break stuff is a viable option there). Some bugs that have been around for a while which finally get assigned to a milestone should not block landings. They may be complex and hard to diagnose and a few people fixing is enough. It doesn't help anyone to hold up the entire dev team over such bugs. Whereas a CI breakage you have clear choices - fix quickly or rollback to unblock. >> 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. > There have been many times we have legitimately needed jfdi. Dev teams exist in a world where pragmatism is usually the best policy, rather than a strict adherence to a policy which has the potential to kill velocity for unequal corresponding benefit. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
