>On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté <[email protected]> wrote: > >> I actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO. >> That way, if you're looking at the bug and want to pull someone in, you CC >> them; if you're looking at the fix and want to involve someone, you add >> them as a subscriber which then incidentally lets them view the bug, for >> background and updates and such. > > >What if there's not "the" fix but multiple patches? This is quite common >for security bugs where a testcase that reveals the vulnerability is done >in a separate patch so it can be checked in after we release the fix. Or >occasionally bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1371259 >that had 9 separate patches. Would the same people have to be separately >subscribed to each?
I've seen landings (for non-security bugs) that involved up to 100 patches on one bug... or even more. While that's probably never happened for a sec bug, multiple patches is not unusual (and in fact common where there's a test added). >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). >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. 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. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
