Thanks for checking the developer guidelines and making sure they are consistent.
I'd like to hear a little more about: branch merges - … I personally wish that especially significant merges *did* have bugs to make it a little easier to track problems back to a branch landing and have a place for discussion of the reasons and risks. There's a discussion I've been in with release mangement about what we can be doing to improve these merges and how we are tracking them and the regressions they may cause. -- Emma On Fri, Feb 3, 2017 at 11:01 AM, Steve Fink <sf...@mozilla.com> wrote: > On 02/03/2017 09:29 AM, Gijs Kruitbosch wrote: > >> On 03/02/2017 15:11, Ryan VanderMeulen wrote: >> >>> A friendly reminder that per the MDN commit rules, the use of "No bug" >>> in the commit message is to be used sparingly - in general for minor things >>> like whitespace changes/comment fixes/etc where traceability isn't as >>> important. >>> https://developer.mozilla.org/docs/Mozilla/Developer_guide/C >>> ommitting_Rules_and_Responsibilities >>> >>> I've come across uses of "No bug" commits recently where entire upstream >>> imports of vendored libraries were done. This is bad for multiple reasons: >>> * If makes sheriffing difficult - if the patch is broken and needs >>> backing out, where should the comment go? When it gets merged to >>> mozilla-central, who gets notified? >>> >> As Greg said, the committer / pusher, via IRC and/or email. >> >>> * It makes tracking a pain - what happens if that patch ends up needing >>> uplift? >>> >> Generally, the person committing it will know whether it needs uplift, >> and would have filed a bug if it did - and would file one if it does after >> the fact. We can already not rely on bugs being marked fixed/verified on a >> trunk branch when searching bugzilla for uplift requests (cf. "disable >> feature Y on beta" bugs) and so I don't see how this is relevant. >> >>> What about when that patch causes conflicts with another patch needing >>> uplift? >>> >> That seems like it hardly ever happens in the example you gave (vendored >> libraries and other wholesale "update this dir to match external canonical >> version"), and if/when it does, the people who would be likely to be >> involved in such changes (effectively changes to vendored deps that aren't >> copied from the same canonical source!) are also likely to be aware of what >> merged when. >> >>> What if it causes a regression and a blocking bug needs to be filed? >>> >> Then you file a bug and needinfo the person who landed the commit (which >> one would generally do anyway, besides just marking it blocking the >> regressor). >> >> >> If there's an overwhelming majority of people who think using "no bug" >> for landing 'sync m-c with repo X' commits is bad, we can make a more >> explicit change in the rules here. But in terms of reducing development >> friction, if we think bugs are necessary at this point, I would prefer >> doing something like what Greg suggested, ie auto-file bugs for commits >> that get pushed that don't have a bug associated with them. >> >> >> More generally, I concur with Greg that we should pivot to having the >> repos be our source of truth about what csets are present on which >> branches. I've seen cases recently where e.g. we land a feature, then there >> are regressions, and some of them are addressed in followup bugs, and then >> eventually we back everything out of one of the trains because we can't fix >> *all* the regressions in time. At that point, the original feature bug's >> flags are updated ('disabled' on the branch with backouts), but not those >> of the regression fix deps, and so if *those* have regressions, people >> filing bugs make incorrect assumptions about what versions are affected. >> Manually tracking branch fix state in bugzilla alone is a losing battle. >> > > For the immediate term, I must respectfully disagree. Sheriffs are the > people most involved with and concerned with the changeset management > procedures, so if the sheriffs (and Ryan "I'm not a sheriff!" VM) are > claiming that No Bug landings are being overused and causing issues, I'm > inclined to adjust current practices first and hold off on rethinking our > development process until the immediate pain is resolved. The fact is that > our *current* changeset management *is* very bug-centric. I think gps and > others have made a good argument for why another process may be superior > (and I personally do not regard our current process as the pinnacle of > efficiency), and I'm all for coming up with something better. But I really > don't want some long drawn-out halfway state where the people who think the > process should be A are doing it that way, the people who think it should > be B are changing piecemeal to get something as close to B as is currently > possible, and the people new to our community are completely baffled and > getting contradictory advice depending on who they talk to. > > Can we clarify with examples of good and bad usages of "No bug"? There > will always be a fuzzy middle (unless we go all-out and say every landing > must be associated with a bug). But I'm hearing some dispute over specific > scenarios, so I think it would be helpful to clarify. I am not the one to > decide such things, but my personal guess would be: > > branch merges - No bug is fine. (And IIUC, you don't need to say "No bug" > for those because the hook accepts /merge/ or something like that.) I > personally wish that especially significant merges *did* have bugs to make > it a little easier to track problems back to a branch landing and have a > place for discussion of the reasons and risks. > > Typo/whitespace - No bug is fine, but if it is associated with a recent > landing of some bug, then you should use that bug number anyway. Makes > uplifts cleaner. > > Trivial bustage fixes - use the bug of the original commit. > > Sync with upstream - use a bug! If it causes intermittents, or changes in > telemetry, or anything, then metadata beyond that stored in the commit is > very likely to be useful. Especially with anything that might potentially > be backported. I understand the argument that we can always file a bug > retroactively, but today our process is bug-centric and can we please not > change that without being fully intentional about it and making sure that > works for everyone (especially the sheriffs) first? > > And after writing this, I went and read the developer guidelines link, and > it seems to agree with all of these. > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
