In the tracking flags, for now, we have: * empty (---) * - * + * ? This is a key element for release management to track bugs during the various cycle (nightly, aurora, beta, release & esr). However, it is hard differentiate bug which would like to see fixed in the release and real blocker bugs. We have identify this as a lack for our work and would like to experiment release management with a new value. The new value "blocker" should be added to the list of values of tracking-firefox44 tracking-firefox45 tracking-firefox46 and the future tracking-firefox.
I would like to suggest that we should use "blocking" as a keyword similar to "crash", "top-crash", "sec-crit", "sec-high". Keyword tagging is an interesting piece of metadata that can be used to mine bugs per release to see how many crashes/sec-rated/regressions bugs were fixed. If we use tracking field to mark bugs as release blocking, then doing data mining becomes harder as we need to correlate meta data from keyword tagging + tracking field.
I don't see that a blocking (!) issue on your side, just making the query a bit more complex, right? I don't like the keyword because: * anyone can touch it. We will have users abusing it or staff touching it. tracking flags have acl * when someone removes the keyword, it will be gone from our queries * blocking implies tracking. If we use tracking flags + keyword, this will add one more step * it is a general information to the bug, not tight to a specific version * they are general to all bugs, so, people could be using it for other projects FYI, I killed the relnotes keyword (cf bug 1190357).
Created attachment 8733791 [details] [diff] [review] Bug 1235667 - Fix the PermissionsUtils.jsm for using createCodebasePrincipal instead of createCodebasePrincipalFromOrigin.
Comment on attachment 8733791 [details] [diff] [review] Bug 1235667 - Fix the PermissionsUtils.jsm for using createCodebasePrincipal instead of createCodebasePrincipalFromOrigin. Sorry that I put wrong patch here. Please Ignore me, thanks.