Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread Laszlo Ersek 
On 03/10/16 18:20, Mangefeste, Tony wrote:
> Very good thoughts, Laszlo.
> 
> The more I think about GitHub integration, the more I'm leaning
> against it.  Another reason is that we can assign groups to certain
> organizational emails to allow/grant special rights to specific
> classes of issues.  For example, it's plausible that we would give
> anyone from *@redhat.com for instance a group that identified them as
> part of that organization and then grant tha ability to perform
> special triage tasks or other organization specific tasks, while
> keeping the content visible to the community.

Sounds great. I think it also matches David's idea.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread Mangefeste, Tony 
Very good thoughts, Laszlo.

The more I think about GitHub integration, the more I'm leaning against it.  
Another reason is that we can assign groups to certain organizational emails to 
allow/grant special rights to specific classes of issues.  For example, it's 
plausible that we would give anyone from *@redhat.com for instance a group that 
identified them as part of that organization and then grant tha ability to 
perform special triage tasks or other organization specific tasks, while 
keeping the content visible to the community. 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, March 10, 2016 2:33 AM
To: Mangefeste, Tony 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] Tianocore Community Update 2016 #1

On 03/09/16 19:49, Mangefeste, Tony wrote:

> I. Defect & Issue Tracking

> There are several topics we're investigating, and your input is appreciated:

First of all, thank you very much for going forward with Bugzilla!

> * Considering tying the Bugzilla login to GitHub using GitHub as the 
> provider.  This would mean that anyone wishing to submit an item into 
> BZ would require a GitHub account.

I vote against this. I find 3rd party authentication providers insecure.
While I find Single Sign On extremely useful (and also secure) in a single, 
centrally managed organization, GitHub and the edk2 Bugzilla (to be operated by 
Intel) are separate entities.

A breach of GitHub could lead to a breach of the Bugzilla, and leakage of 
sensitive data (private comments, private bugs, private attachments).

Downtime of GitHub would prevent us from logging into Bugzilla.

Modern browsers have built-in password managers. The practice I generally 
follow is to have a unique, complex, machine-generated password for every 
public-facing website, and to store those in a reliable password manager 
(behind a very strong master password of coruse).

--*--

Another practical remark: I insist on having access to the personal email 
addresses of people who report bugs, for two reasons.

Less importantly, I want to be able to contact them in email, outside of 
bugzilla (they might have some files I need for debugging, but their data is 
too sensitive or too big to attach to the bug).

More importantly, if I write patches for a BZ entry (bug or feature request), I 
always CC the reporter on the patches. Now, purely for informing the reporter 
about the patches, my "other" best practice would suffice in itself -- that 
best practice being: I link every patch submisson from the mailing list archive 
immediately into the bug --, but the main goal is that I want his/her testing 
feedback. For that the reporter should be able to build my patches, hence I CC 
him/her directly. Therefore I need his/her email address on the bug.

Fishing the emails of reporters out of GitHub's issue tracker has been a pain. 
One clicks the "@reporter_nick" style link in the discussion, and hopes that 
the reporter's profile page lists his/her email address publicly. If it 
doesn't, then I have to ask for it in the tracker entry explicitly, or I can 
try googling it.

Bugzilla normally gives me the email addresses of all commenters on the bug 
automatically, and so it should be.

(Example: my profile page <https://github.com/lersek/> does not list my email 
address either. Why? Because I don't like spam, and my email is trivially 
googleable for humans, from my name & employer. The point with Bugzilla is that 
it only exposes email addresses to logged in users (no bots), but then logged 
in users do get all the addresses without further
obstacles.)

I'm worried that if GitHub provided the authentication for Bugzilla, it could 
withhold email addresses from Bugzilla, and break the above use case.

Thank you
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread Laszlo Ersek 
On 03/10/16 14:11, David Woodhouse wrote:
> On Thu, 2016-03-10 at 13:58 +0100, Laszlo Ersek wrote:
>>
>>> Sure, actually getting vendor buy-in for that is a completely different
>>> story. But let's not design the system to make it hard :)
>>
>> I couldn't buy in.
> 
> That's fine. I'm not asking you to. I'm just asking that we don't make
> it *harder*.
> 

Okay.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread David Woodhouse 
On Thu, 2016-03-10 at 13:58 +0100, Laszlo Ersek wrote:
> 
> > Sure, actually getting vendor buy-in for that is a completely different
> > story. But let's not design the system to make it hard :)
> 
> I couldn't buy in.

That's fine. I'm not asking you to. I'm just asking that we don't make
it *harder*.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread Laszlo Ersek 
On 03/10/16 11:58, David Woodhouse wrote:
> On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote:
>>
>>> * Considering tying the Bugzilla login to GitHub using GitHub as the
>>> provider.  This would mean that anyone wishing to submit an item into
>>> BZ would require a GitHub account.
>>
>> I vote against this. I find 3rd party authentication providers insecure.
> 
> I concur.
> 
> The end goal should be a coherent bug tracking system where a user can
> file a bug, and it can be reassigned to TianoCore or to a specific
> vendor's "value subtract",

I think a cross-vendor tracker is too steep. Usually vendors (including
Red Hat) have their own public trackers already. For example, in Red Hat
Bugzilla you can report bugs for (downstream) OVMF today.

In Red Hat Bugzilla, bugs reported for downstream components that need
upstream fixes first are handled in two three ways:

- Sometimes the community decides to use Red Hat Bugzilla for upstream
tracking. (Example: libvirt.) In this case, RHBZ receives two bugs: one
for upstream, one for downstream. One is usually a clone of the other
(within a single BZ instance, you can clone bugs, and their dependencies
are set up automatically). They are also reported for separate products.

- If the upstream project has an independent tracker, then RHBZ offers
metadata fields for linking the upstream tracker entry. It even has some
ingrained knowledge about specific high-profile upstream trackers
(FreeDesktop.org Bugzilla, GCC Bugzilla, Kernel Bugzilla, and so on.)

- If the upstream project lacks a tracker completely, then the important
upstream mailing list threads are linked as comments in the RHBZ entry
(problem report message, patch submissions, and so on). The hashes of
the commits that fix the issue are also captured in a comment. (If the
upstream project has its own tracker, then the hashes are (should be)
listed there.)

> and its *whole* lifetime can be tracked
> until a fix is released for the specific instance that the user has
> reported it with.
> 
> For that, we *are* going to need the thing to live under the auspices
> of the UEFI Forum, and we are going to need to be able to mark things
> as private — using an account system that is *directly* under our
> control.

I don't think I'd be permitted to store data (private comments, for
example) related to product planning in an external tracker. Product
planning and many other managerial workflows can depend on bug metadata
that are specific to a company or a department.

I think a cross-vendor tracker is too much; my vote is an upstream-only
tracker.

> Sure, actually getting vendor buy-in for that is a completely different
> story. But let's not design the system to make it hard :)

I couldn't buy in.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread David Woodhouse 
On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote:
> 
> > * Considering tying the Bugzilla login to GitHub using GitHub as the
> > provider.  This would mean that anyone wishing to submit an item into
> > BZ would require a GitHub account.
> 
> I vote against this. I find 3rd party authentication providers insecure.

I concur.

The end goal should be a coherent bug tracking system where a user can
file a bug, and it can be reassigned to TianoCore or to a specific
vendor's "value subtract", and its *whole* lifetime can be tracked
until a fix is released for the specific instance that the user has
reported it with.

For that, we *are* going to need the thing to live under the auspices
of the UEFI Forum, and we are going to need to be able to mark things
as private — using an account system that is *directly* under our
control.

Sure, actually getting vendor buy-in for that is a completely different
story. But let's not design the system to make it hard :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

2016-03-10 Thread Laszlo Ersek 
On 03/09/16 19:49, Mangefeste, Tony wrote:

> I. Defect & Issue Tracking

> There are several topics we're investigating, and your input is appreciated:

First of all, thank you very much for going forward with Bugzilla!

> * Considering tying the Bugzilla login to GitHub using GitHub as the
> provider.  This would mean that anyone wishing to submit an item into
> BZ would require a GitHub account.

I vote against this. I find 3rd party authentication providers insecure.
While I find Single Sign On extremely useful (and also secure) in a
single, centrally managed organization, GitHub and the edk2 Bugzilla (to
be operated by Intel) are separate entities.

A breach of GitHub could lead to a breach of the Bugzilla, and leakage
of sensitive data (private comments, private bugs, private attachments).

Downtime of GitHub would prevent us from logging into Bugzilla.

Modern browsers have built-in password managers. The practice I
generally follow is to have a unique, complex, machine-generated
password for every public-facing website, and to store those in a
reliable password manager (behind a very strong master password of coruse).

--*--

Another practical remark: I insist on having access to the personal
email addresses of people who report bugs, for two reasons.

Less importantly, I want to be able to contact them in email, outside of
bugzilla (they might have some files I need for debugging, but their
data is too sensitive or too big to attach to the bug).

More importantly, if I write patches for a BZ entry (bug or feature
request), I always CC the reporter on the patches. Now, purely for
informing the reporter about the patches, my "other" best practice would
suffice in itself -- that best practice being: I link every patch
submisson from the mailing list archive immediately into the bug --, but
the main goal is that I want his/her testing feedback. For that the
reporter should be able to build my patches, hence I CC him/her
directly. Therefore I need his/her email address on the bug.

Fishing the emails of reporters out of GitHub's issue tracker has been a
pain. One clicks the "@reporter_nick" style link in the discussion, and
hopes that the reporter's profile page lists his/her email address
publicly. If it doesn't, then I have to ask for it in the tracker entry
explicitly, or I can try googling it.

Bugzilla normally gives me the email addresses of all commenters on the
bug automatically, and so it should be.

(Example: my profile page  does not list my
email address either. Why? Because I don't like spam, and my email is
trivially googleable for humans, from my name & employer. The point with
Bugzilla is that it only exposes email addresses to logged in users (no
bots), but then logged in users do get all the addresses without further
obstacles.)

I'm worried that if GitHub provided the authentication for Bugzilla, it
could withhold email addresses from Bugzilla, and break the above use case.

Thank you
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Tianocore Community Update 2016 #1

2016-03-09 Thread Mangefeste, Tony 
Hello Tianocore Community!

It's been a few weeks since my last update, or rather introductions, into the 
community.  It's time for a sync.  As always the goal is to be transparent with 
how we work as a community, and with that in mind here are some updates to 
provide to you all.

I. Defect & Issue Tracking

As you may have read on the list, we're going to move towards having a Bugzilla 
system in place for us to track work items, defects, and features asks.  This 
is part of a broader plan that we'll roll out and discuss regarding how we 
improve the Tianocore program cadence, and how improve the quality of our code. 
 But for now, the update is that we're moving forward with a Bugzilla server.  
Unfortunately, that server is inside of Intel's firewall, and I'm working to 
get it on the DMZ so that the community can poke at it, provide feedback, and 
we can iterate before going live.  

There are several topics we're investigating, and your input is appreciated:
* Considering tying the Bugzilla login to GitHub using GitHub as the 
provider.  This would mean that anyone wishing to submit an item into BZ would 
require a GitHub account.
* Requirements from the previous exchange on this list about the need 
for groups in general to protect sensitive issues that may be filed. (e.g. 
security)
* And we're going to consider adding a test repository along with the 
ability to link issues with test cases.

The next steps are fluid at the moment, but I promise an update in the next few 
weeks.  I will be providing an update by the end of the month.

II. Governance

We're naming three individuals who will act as Tianocore stewards.  These three 
individuals and I will work with the community to facilitate design 
conversations, carry through difficult decisions, and in general as their name 
suggest offer "stewardship" of the code.  I'm happy to announce that:
* Andrew Fish (Apple)
* Leif Lindholm (Linaro)
* Mike Kinney (Intel)

Are our first set of folks who will be acting in this role.  We'll be rolling 
out more details soon on their specific functions and duty, but for now I 
wanted to make sure everyone is aware of this change.   We're going to be 
rolling out several areas of focus for the community, which will also include 
improved codification of the edk2 development process.

III. Staging Area

Along with an announcement in governance, we've made a decision to offer up a 
standing repository so that the community can prototype, validate, and 
otherwise experiment with features before they get rolled into the main EDK2 
trunk.  Please review the follow-up email (sent separately) to comment on the 
process.  We'll also add it to the wiki after initial comments.

Regards,
Tony

PS. I'll be uploading these into the wiki as time goes on for these updates.

---
Tony Mangefeste
Intel Corporation
STO/SMC
Community Technology Lead
Tianocore Community Manager
g+: https://goo.gl/l5B5JH
t: @tonymangefeste


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel