On Saturday, 26 August 2017 00:40:08 UTC-4, Randell Jesup wrote: > >And don't forget reporter and assignees. Occasionally a reporter not in the > >security group will notice that a patch is insufficient which is nicer to > >find before the patch is committed than after the commit link is added to > >the bug. Sometimes someone other than the official assignee adds a patch > >for an alternate approach to a fix and asks the assignee for feedback, > >though that's uncommon and the assignee could just be manually subscribed > >to the patch at that point. > > In fact it's quite common for people who are cc'd other than the patch > writer and reviewer(s) to look at the bug and comment on it, or to > submit an alternate or modified version of a patch previously uploaded. > And as Dan points out, frequently the reporter (when an external > 'researcher') will weigh in on the patches being posted or use them to > verify if they fix the problem they found (since many times only they > can reliably reproduce the problem - private test setups, drivers, HW, etc).
Right, it's easy to add the reporter since that person won't change. The assignee will also automatically have access if they are the patch author. I also got some data from BMO that strongly suggests that, indeed, many people who aren't the author or reviewer look at sec-bug patches, and most of those aren't in the sec group; they have access by being CCed in. That's surprising to me, but it definitely suggests the need for syncing the bug's CC list to the revision's subscriber list. > >We can wait and see how common the "please subscribe me to the patch" > >requests are, but I suspect they'll be common enough. > > Bite the bullet and at least make all CC'd people able to see all > patches, always. It's needed. Yeah, that's the direction I think we should take. For now, we will implement exact syncing of the CC list + reporter as the revision's subscriber list. This means that anyone being added as a subscriber who isn't CCed will unfortunately be quickly removed (we may even prevent manual additions to the subscriber list). The reasoning here is that I believe it's important that anyone looking at the bug knows exactly who can see the patch. If the two lists are kept in sync, it will be obvious. However, if we let people add subscribers directly, then it may turn out that a bug with only, say, 10 CCed people might have a patch that 100 people can view, and that's probably something you don't want to hide. We'll also investigate what bidirectional syncing would take. Due to race conditions and circular references, though, it won't be straightforward, and I suspect our time would be best spent elsewhere. We can and will revisit this after Phabricator goes live for everyone. > Another aspect of all this that needs to be thought out and verified is > what happens when a non-sec bug becomes a sec bug (and vice-versa, > though I'm far less concerned about that). When a bug becomes a sec > bug, all patches associated with that bug must become confidential. And > when a bug moves to be open (not sec-restricted), the patches should > also become open. Of course. This is already implemented. Mark _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
