Re: [onap-tsc] Committers and voting - Please read.

[MAHER, RANDA]

+1

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of SPATSCHECK, OLIVER
Sent: Friday, June 30, 2017 11:57 AM
To: Andrew Grimberg <agrimb...@linuxfoundation.org>
Cc: t...@lists.onap.org
Subject: Re: [onap-tsc] Committers and voting - Please read.

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
+1


On Jun 30, 2017, at 11:41 AM, Andrew Grimberg 
<agrimb...@linuxfoundation.org<mailto:agrimb...@linuxfoundation.org>> wrote:

To help weed things down I would suggest that every repository in a
project be required to define a distinct list of committers and not
allow an umbrella project to define top level committers. That list may
be the same across several of them, but they should be distinct to each
repository and hold to the same configuration of just a few committers
per repository. It may mean a bit more administrative overhead for the
management, and definitely for the set-up but it will clearly define who
does, and does not have domain knowledge on a particular set of code.


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Committers and voting - Please read.

[Ed Warnicke]

Something else that helps a great deal is for the original author of the
proposal to be the gatekeeper on changes to the proposal, including adding
committers.  Wiki's are wonderful in that anyone can fix anything, but for
project proposals, editing them to shift without consent their intent or
original initial committer list is strongly at the root of the problem.  It
also allows the TSC to be *thoughtfully* flexible in places, because it can
then ask the proposer "Why do you have 6 committers?".  Sometimes there
*will* be a good reason, and in the situations where there isn't one... the
*fact* that the proposer knows they will be asked will likely lead to the
correct outcome long before it comes to the TSC.

Ed

On Fri, Jun 30, 2017 at 8:56 AM, SPATSCHECK, OLIVER (OLIVER) <
spat...@research.att.com> wrote:

> +1
>
>
> On Jun 30, 2017, at 11:41 AM, Andrew Grimberg <
> agrimb...@linuxfoundation.org> wrote:
>
> To help weed things down I would suggest that every repository in a
> project be required to define a distinct list of committers and not
> allow an umbrella project to define top level committers. That list may
> be the same across several of them, but they should be distinct to each
> repository and hold to the same configuration of just a few committers
> per repository. It may mean a bit more administrative overhead for the
> management, and definitely for the set-up but it will clearly define who
> does, and does not have domain knowledge on a particular set of code.
>
>
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Committers and voting - Please read.

[SPATSCHECK, OLIVER (OLIVER)]

+1


On Jun 30, 2017, at 11:41 AM, Andrew Grimberg 
> wrote:

To help weed things down I would suggest that every repository in a
project be required to define a distinct list of committers and not
allow an umbrella project to define top level committers. That list may
be the same across several of them, but they should be distinct to each
repository and hold to the same configuration of just a few committers
per repository. It may mean a bit more administrative overhead for the
management, and definitely for the set-up but it will clearly define who
does, and does not have domain knowledge on a particular set of code.


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Committers and voting - Please read.

[Andrew Grimberg]

On 06/30/2017 07:00 AM, SPATSCHECK, OLIVER  (OLIVER) wrote:

> I think the TSC needs to either step up and enforce it’s own rules or
> abandon the rule altogether. The current status quo punish people which
> play by the rules which I would think is not the intend of the TSC.
> 
> I would be interested to hear how the open source “gurus” have handled
> this in the past as I suspect this has happened before in other projects.

Oliver,

As you state, the TSC sort of needs to be more willing to vote -1 on
creation if the committer list is really bad. Our other communities have
generally held the line during the review process so don't really have
the problem. What we've seen instead is that as a project matures the
list may grow to be a bit larger than is initially thought to be good,
but the number of committers tends to flex up to what is needed instead
of trying to trim down.

What you end up needing to do is have the PTL start working on trimming
the committer list and have current committers voluntarily step down.

I'll also note, that the large lists of committers is also likely partly
a result of the umbrella project methodology of committer definition as
person X may need committer on sub-project Y but with how the lists are
currently defined, it's basically only at the top level umbrella level.

To help weed things down I would suggest that every repository in a
project be required to define a distinct list of committers and not
allow an umbrella project to define top level committers. That list may
be the same across several of them, but they should be distinct to each
repository and hold to the same configuration of just a few committers
per repository. It may mean a bit more administrative overhead for the
management, and definitely for the set-up but it will clearly define who
does, and does not have domain knowledge on a particular set of code.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Committers and voting - Please read.

[SPATSCHECK, OLIVER (OLIVER)]

Mazin,

your email triggered me to actually go through the wiki and get some stats. I 
attached a spreadsheet with committers per company and project (I did this 
manually so there might be some minor mistakes but the trend holds). Also the 
companies are sorted by appearance so the order is random.

Seems the TSC has failed miserably enforcing it’s own policies.

The average number of committers is 8.6. The max is 26 the min is 1.  Based on 
the 27 approved projects on the wiki 15 are not in compliance of the policy. 
There are 10 projects with more then 10 committers.

Looking at some of the trends it seems to be a self feeding process one company 
adds more then the others don’t want to be “left out” and respond in kind. So 
it’s more driven by ego/politics then merit in most cases I can see.

I think the TSC needs to either step up and enforce it’s own rules or abandon 
the rule altogether. The current status quo punish people which play by the 
rules which I would think is not the intend of the TSC.

I would be interested to hear how the open source “gurus” have handled this in 
the past as I suspect this has happened before in other projects.

Oliver



On Jun 29, 2017, at 9:35 PM, GILBERT, MAZIN E (MAZIN E) 
> wrote:

*** Security Advisory: This Message Originated Outside of AT ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

ONAP Community,

I have sent a note on this before, so my apology for sending it again.
It is important that this community follow the guidelines of the TSC on
committers and PTLs. We have provided guidelines that projects should
have between 3-5 committers that have actual development experience
and deep knowledge in the software or release software. While I love
the passion and involvement of the community, I see few projects that
misused those directions and ended up with committers in excess of 10, some
signed up the last minute to steer the PTL vote.

I hesitated to manage and clean-up the committers per advice from
the Linux Foundation, but I will ask the TSC to enforce those guidelines
in future to ensure fair outcomes across all projects.

Thank you.. I will soon share some great news of new exciting members who
are joining ONAP. Thank you again for your hard work to making ONAP
a success and let’s make the Amsterdam Release a blast.

Mazin

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=rUHhj9ph_CQ3Np2G-F9zUffASbFXC8e__XGg_VFgjtE=AOatY2_khrWMjoCancKkJNqTK5U3Z5woGJ-3-uMx4jY=



CommiterMatrix.xlsx
Description: CommiterMatrix.xlsx
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc