Ok, this may not be as constructive as
I initially suggested, but to address other PMC members concerns (and community
concerns), I will "-1" current nominations.
But that is not near as negative as
it sounds. As your contributors develop some history "in the open",
that you can document, then please renominate them. You do not have to
wait and do all 6 at once :) ... I expect these will get more scrutiny
the second time through, so suggest there be several substantiative contributions
that show knowledge of domain and the code -- not just "cleaning up
warnings" or similar easy things. IMO, 4 or 5 such commits would suffice.
BTW, it is important that potential committers do have "commits",
but there can be supportive information, such as presentations, wiki authorship,
mailing list activity, etc., if that helps you document their "open"
And again, nothing about this is meant
to say any of the nominees is "unworthy" -- it is a matter of
demonstrating a history with the project that demonstrates "commitment"
(conceptually) and merit in an open and transparent way.
In the long run, your project will be
better off doing things more transparently and "in the open",
though I am aware it is not always as easy as having a closed code base
that is occasionally made open.
BTW, given these "-1s" I
do not think the project needs to be literally "rebooted" as
some have suggested, and we will trust that who ever committed the large
"sync with internal servers" did do their committer duty and
ensured all changes were "legal", permissible, etc. before committing.
If any PMC members disagree with me,
I am sure they will speak up, and they will initiate what ever they think
needs to be done.
Elemér Lelik <elemer.lelik@xxxxxxxxxxxx> To:
Tools PMC mailing list
03/11/2016 10:07 AM Subject:
Fw: PMC approval needed for committer vote for .... Sent by:
Hi David et al.
I appreciate your constructive
approach. We are working on filing in the gaps of authoring information
, which indeed is not entirely complete.
On Behalf Of David M Williams Sent: Wednesday, March 09, 2016 8:08 PM To: Tools PMC mailing list Cc: titan-dev@xxxxxxxxxxx Subject: Re: [tools-pmc] Fw: PMC approval needed for committer vote
This sounds ok to me. But, I will wait a
few days to +1 to see if any one else has any comments.
BTW, even if done "internally" and then "sync'd" up,
I would think they would still show up as "'authors" of the 'commits'
in the repository. If that is not the case, then that might indicate a
problem with your use of Git -- not quite using the correct workflow. Normally,
when doing work 'in the open' (especially at Eclipse) you want to be sure
the author of the commit is maintained, even if someone else commits it
to the repository. If you need help with that, please ask. But, it could
be just that your internal workflow was such that you sort of "lost"
who the author was.
Thanks for your reply -- and thanks for moving to doing "development
in the open".
I understand your confusion and I ‘m the guilty one for creating such
a confusing situation.
Let me explain: the development of Eclipse Titan is
ongoing in Ericsson, and there’s a developer team taking care of
that. Up until recently, the workflow was to update from time to
time the public github repositories from our internal git repositories ( which usually was proxied by
me) , but Wayne pointed out that this is not in accordance with the transparency
and openness required by the Eclipse development model. Which we understood and now we are preparing to move all our development
in the open; but for this the whole team needs committer rights so they
can continue working in github (and Bugzilla etc.) under the
same conditions they did before internally. So the new committer rights requested are for developers who are
de facto developing Titan currently. Once committer rights attributed
, we can cut over to the tools provided by Eclipse.
I hope this is will be favorably acknowledged by the PMC.
We, the Tools PMC were asked to approve 6 new committer elections similar
to the attached one. Normally that is a wonderful thing. But, in this case,
there was no evidence given of Eclipse commits or history, which is typically
required to become a new committer. That is how Eclipse ensures "merit"
and not simply that someone, say, works for a certain employer.
Normally, if a project has "just started" we do not mind bending
the rules a little, but Titan has been at Eclipse for one year now, so
I would think that is time enough to learn the Eclipse rules and process,
and also time enough for new committers to develop some history with the
So can Elemer or someone explain to the PMC a little more what this is
about? Did the nominations just fail to mention the commits and history
at Eclipse? Was there some special new contribution of code? Or is there
a misunderstanding of what it takes to become a new committer?
I don't mean to slow things down, and certainly don't want to discourage
new committers -- I am sure they are all worthy. But, I do feel an obligation
to "enforce the rules" that everyone must follow since every
exception makes the next one easier, until there are no rules at all! Especially
for 6 committers at once! Makes me think something is going on that is
not well understood or documented?
----- Forwarded by David M Williams/Raleigh/IBM on 03/08/2016 04:19 PM
tools PMC Members, This automatically generated message marks the completion of voting for Arpad Lovassy's Committer status on the tools.titan project. As a PMC member, you can approve or disapprove this vote through your My Foundation portal page: