>On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté <mc...@mozilla.com> 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

Reply via email to