Ideally we would be doing it in a way that we can audit things quickly in the case we think a bad actor has compromised someone's machine.
While we can say what we want and how we want the process, we need to work with what we have until we have a better process. This could be between now and the end of the year. Ideally, and hopefully its not too far away, all pushes will be going through autoland and then we won't have situations like this. In the short term, when the sheriffs do merges I will be getting them to have a look at all "no bug" pushes. Anything that goes outside of https://developer.mozilla.org/docs/Mozilla/Developer_guide/C ommitting_Rules_and_Responsibilities will be followed up. David On 3 February 2017 at 19:01, 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
