“Fixed:” in CL descriptions, “Bug:” + Status=Fixed
Dan Beam
[If you don’t commit CLs that fix bugs, you can stop reading now.]
I’m happy to introduce “Fixed: [bug-id…]”, a new syntax for Chromium (and other[1]) CL descriptions. The format is the same as “Bug: [bug-id…]” and runs the same steps (posts a comment on the listed bug[s] when the CL lands), but it also sets the bug’s Status to “Fixed”.
Why do we need this?
Marking a bug fixed after a CL lands is a common use case. However, because of the manual nature of needing to remember things :) (and the helpfully, increasingly automated CQ), there’s commonly substantial time between the CL landing and somebody remembering to mark the bug fixed (if they do). Hopefully “Fixed:” reduces the need for “is this bug fixed?” comments.
How do I use it?
Change “Bug:” to “Fixed:” in your CL desc, add --fixed [bug-id] (or -x [bug-id]) to `git cl upload`, or name your local git branch “fixed-#-[optional-more-words]”.
Does this add more bug comments or send more emails?
Nope! You’ll just see “Status: Fixed” being set at the same time when a comment is posted (in the same 1 email that you’re used to getting).
Can I used FIXED= instead?
No, “FIXED=” syntax is not supported. Presubmits will detect this and suggest “Fixed: “ instead.
Why “Fixed:” but not “FIXED=” or “Fixes:”?
“Fixed:” follows the git-footers and git interpret-trailers formats. BUG=, R=, and TBR= tags are currently supported for legacy reasons. “Fixed:” (past) instead of “Fixes:” (present) as it’s consistent with existing syntaxes and hopefully most of the listed bugs stay fixed :).
My project doesn’t use Status=Fixed / are there plans to support other statuses?
There’s currently no plans to support setting statuses other than “Fixed” when a CL lands (at least by me) via CL description. If your project uses a status other than “Fixed” (e.g. “FixPending”) you will currently not benefit from using “Fixed”.
Does reverting a CL with “Fixed: [bug-id...]” in the description reopen [bug-id...]?
No; not currently. This could make sense, I’m just not sure about situations like:
a revert is the fix for a bug
reverting shouldn’t reopen (e.g. disable a feature on HEAD right before a branch cut, revert after)
-- Dan
[1] “Fixed:” should work for any project that uses Bugdroid + Monorail. Let me know if that’s not the case.
PhistucK
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CANNW_QogrSKe_eFC7%2BvsZRGViq7BmTgo6qhTQSQ47siywhm9KQ%40mail.gmail.com.