Hi,
The TSC composition discussions are always tricky. The idea behind the current
formulation was:
* TSC members should be active community members (and while the active
definition could be debated, it was also lifted from OPNFV).
* TSC members should be voted by active community members
* When nominating to the TSC, the individuals self nominate as a candidate.
* Max 18 TSC members.
* A set of defined Operators should have a reserved seat at the TSC (while
still respecting the intent of the above):
* This implied that if there were active members from one of the defined
operators, it was one or more of those that were eligible to be a candidate.
This was to respect the wish to have active community members in the TSC.
* There was a clause put in to address the two cases where either the
operator was new and didn’t have eligible candidates; or the proposed
candidates were not elected, the defined operators could anyway select a person
to be a TSC representative (which still had to be an active member (if
available) to respect the criteria to have a active community member). This
was to respect the decision to have reserved seats for the defined operator.
While not all may have agreed to this, for example there was debate about:
* What constitutes an active member.
* Whether there really should be reserved seats for the operators (should
it really be a 50/50 split, why should there be reserved seats at all, how to
define operator vs vendor, ….)
* Was 18 the correct number of TSC participants
* Should operators be allowed to select anyone, or should it be an active
member.
While I think that most people who participated in the discussion would have
some element of the current formulation that they do not really like, it was
what was decided, and until there is another discussion on the TSC composition
rules, my view is that it should be respected and not worked around, as
workarounds go against transparency and the spirit of a community agreement.
At some stage I can presume the TSC composition rules will be debated again,
and it won’t only be the rules for the reserved operator seats that would be
re-considered but whether there should be reserved seats at all, definition of
active members, the TSC size etc.
I think this points to that contributions should be individual. There maybe
other aspects such as individual contribution agreements etc that may also be
tricky otherwise when that comes into play. I think that there are mechanisms
to attribute a set of email addresses to a company in the magic that Kenny
works with if that is what needs to be solved.
Anyway, this is one input into the discussion.
BR,
Steve
From: [email protected] <[email protected]> On Behalf Of Marcus G K
Williams
Sent: Wednesday 10 April 2019 17:05
To: Cherubini, Davide, Vodafone Group <[email protected]>; Seshu m
<[email protected]>; [email protected]; Kenny Paul
<[email protected]>; Phil Robb <[email protected]>
Cc: Abu Aisheh, Razanne, Vodafone Group <[email protected]>
Subject: Re: [onap-tsc] Commit Code on Common Account? - SO-1421 code review
Davide, Thanks for explaining your reasoning.
* TSC, what is your position on code authorship?
Vodafone is submitting code under a group account due to the TSC election
eligibility rules (see Davide’s email below). They are putting co-authors in
the patches (who are the author), but the author and committer appears as
Vodafone
Group<https://gerrit.onap.org/r/#/q/owner:onap%2540vodafone.com+status:open>.
This seems like bad open source practice and precedent to me and at first I -2
their patch.
I’m a committer in SO, APPC and former committer in SDNC, CCSDK, OpenDaylight
and OPNFV. I’ve contributed to those projects and OpenStack. Based on Open
Source precedent with very few exceptions we should be pushing, authoring,
committing and merging code as individuals. The reason other open source
projects don’t generally allow this is that it opens a host of code
administration and management issues for large projects and it generally
increases the amount of time the already time strapped committers/PTLs need to
take when approving/managing code base.
* Is there a middle ground on TSC elections eligibility we can find?
* Or is this practice fine in the TSC’s mind?
Thanks,
Marcus Williams
IRC, Twitter, etc. @ mgkwill
Intel Corp.
From: Cherubini, Davide, Vodafone Group [mailto:[email protected]]
Sent: Wednesday, April 10, 2019 7:42 AM
To: Williams, Marcus
<[email protected]<mailto:[email protected]>>; Seshu m
<[email protected]<mailto:[email protected]>>
Cc: Abu Aisheh, Razanne, Vodafone Group
<[email protected]<mailto:[email protected]>>
Subject: Re: SO-1421 code review
Hi Marcus,
I agree with you the best practice is to commit the code with real names.
The reason behind the decision to commit with a common email (and have the
engineer who wrote the code added as co-author) is based on the fact that stats
are registered by “author” (which is , btw, correct).
However, those stats are then used to “identify” the person that can be elected
to the TSC (that’s a rule decided some time ago). We have always opposed that
rule because Vodafone is a very big company and we use external (read
non-Vodafone) developers to write part of the code. In the past (although
briefly) it has come to my attention that one of those external consultants
resulted to be the “TSC-eligible” person for Vodafone which, of course, it does
not make any sense.
So the options I see are 3:
1. We review the TSC rule, e.g., by measuring the stats per Company and not
per Individual Contributor. In that way the external developers (who have a
Vodafone email account) can commit the code using their names and avoid the
risk to become the TSC candidate (the TSC candidate for Vodafone should be
decided BY Vodafone)
2. The external developer writes the code and then she/he submits it using
one of the Vodafone architects accounts. I don’t like this option because,
e.g., I should share my LFN account details with external employees
3. The external developer writes the code and then she/he submits it using
the common Vodafone account (the name of the developer is always added as
“co-author”). This is our current option
I hope this clarifies our decision.
Many thanks
[https://www.vodafone.com/content/dam/global_email_signature/New_VF_Icon_RGB_RED.jpg]<http://vodafone.com/>
Davide Cherubini
Lead Software, Open Source and Labs
Strategy, Planning and Operations
Cloud & Automation CoE
Babbage House, The Connection, Newbury, Berkshire RG14 2FN
+44 7770 700172
[email protected]<mailto:[email protected]>
vodafone.com<http://vodafone.com/>
The future is exciting.
Ready?
From: "Williams, Marcus"
<[email protected]<mailto:[email protected]>>
Date: Wednesday, 10 April 2019 at 15:20
To: Razanne Abu Aisheh
<[email protected]<mailto:[email protected]>>, Seshu
m <[email protected]<mailto:[email protected]>>
Cc: Davide Cherubini
<[email protected]<mailto:[email protected]>>
Subject: RE: SO-1421 code review
HI All,
I’ve removed my -2 based on our chat in the SO Weekly Call. I still think this
is bad precedent to set in an Open Source project. What is Vodafone’s issue
with having engineers submit their code with their name and Vodafone email,
just like everyone else? I think we should have a chat in TSC about code
authorship.
The reason other open source projects don’t generally allow this is that it
opens a host of code administration and management issues for large projects
and it generally increases the amount of time the already time strapped
committers/PTLs need to take when approving/managing code.
Just my 2 cents.
Thanks,
Marcus Williams
IRC, Twitter, etc. @ mgkwill
Intel Corp.
From: Abu Aisheh, Razanne, Vodafone Group
[mailto:[email protected]]
Sent: Wednesday, April 10, 2019 3:08 AM
To: Seshu m <[email protected]<mailto:[email protected]>>;
Williams, Marcus <[email protected]<mailto:[email protected]>>
Cc: Cherubini, Davide, Vodafone Group
<[email protected]<mailto:[email protected]>>
Subject: SO-1421 code review
Hi Seshu/Marcus,
We’ve got a comment from Marcus “Please, rebase this change and submit it with
a person as the author and committer” for below given two commits:
1. SO: https://gerrit.onap.org/r/#/c/82798/
2. SO/chef-repo: https://gerrit.onap.org/r/#/c/82816/
However, the commit for OOM (https://gerrit.onap.org/r/#/c/84475/) seems to
have been accepted and merged with the same Vodafone id. We have been using
Vodafone ONAP competency ID to commit the code into ONAP Gerrit. The mail box
for this email ID is actively monitored by the members of the ONAP competency
group and for additional reference, we mentioned the ID of the developer in the
Co-Authored field.
PFA – The code that is committed by the same id and merged with master branch.
Regards,
Razanne
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4822): https://lists.onap.org/g/onap-tsc/message/4822
Mute This Topic: https://lists.onap.org/mt/31019923/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
