[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-pmc] Additional spec lead for servlet-api?
|
Hi,
I'm not exactly sure where to jump in on this.
As Wayne points out, it is, within the policy of the EE4J working
group, that a (single) committer member could be appointed if an
organization wishes. He states this has only happened once. The
detail describing the policy for appointment is here.
My suspicion is that many committer members were included in the
original project inception proposals. That is the only other
avenue for a committer member appointment. All of those proposals,
along with the original committer lists are published -- here.
There shouldn't be any distinction between committers --
regardless if they were designated at the inception of the
project, or if they were elected or appointed (in my opinion
anyway). The Eclipse process doesn't give the Lead any more sway
that a Committer in most technical work. I think we all want that.
All activity in the GitHub repositories is logged so if there is
an activity that is in dispute, it can be rolled back, as easily
by a committer as by a lead, I think.
As was made very clear to me in the early days of this effort --
being a committer should not be treated lightly expressly because
there are few things that a committer cannot do, within the
boundaries of a project's resources. That is true for all Eclipse
projects. Not just Jakarta / EE4J projects.
If you haven't already, I'd recommend you review the following
two documents: The
Eclipse Developer Handbook -- Section on Elections, and The
Eclipse Development Process document (sections 4.1 and 4.6
(about project leaders) and 4.7 (about committers). Scanning the
whole thing might not be a bad idea. Wayne might have more insight
into how these documents relate.
I think that the only things a lead can do, that other committers
cannot are administrative. I'm not 100% sure what those really are
nor how these actions might be taken. Wayne has a several nice
adjunct write-ups on his blog.
The whole thing is worth a scan. You might decide just to start
with his "Eclipse-101"
tags. Some of his content has been picked up in "print" magazines
too.
If there is disruptive behavior, I would encourage any committer
member to first discuss that directly with the committer (or
committers) engaging in that behavior. It is highly likely this
will resolve the issue and no further action would be necessary.
The EDP (section (4.6) includes a leadership escalation chain if
it comes to that: committer members -> project lead -> PMC
-> EMO -> EMO Executive Director). I am pretty confident
that no one wants or intends to resort to escalation procedures.
I believe the default review procedure at GitHub is one review
approval, and then the PR can be merged. In some cases, projects
have established different requirements for reviews and merges
(Jakarta RESTful Web Services, for example). If you feel your
project needs additional process, you can have that set up. If
your project deviates from the "default," it will be very helpful
if you would document that in the project's CONTRIBUTING file (or
files if there is more than one repository in your project).
I would completely support project committer groups getting
together, and starting to discuss their components, proposed
process, and plans. Leads could take an initiative to do this --
or anyone who is a committer could do that as well. So -- right
now is a great time to get to know your fellow committer members.
All that said, we have tried to stay out of this discussion and
allow the project committer teams to organize as they choose. So,
feel free to continue organizing. Organization is great. Improving
participation is greater still.
Set up a call or circulate something to get feedback -- Engage!
(to quote Jean-Luc).
-- Ed
On 1/23/2020 3:03 PM, Reza Rahman
wrote:
This is my personal interpretation
only, but I think what happens in practice is it isn't really
complete anarchy and there is actually informal
leadership/structure amongst the people that really contribute.
It is "merely" earned instead of assigned perhaps. I think you
certainly have earned a leadership role in Servlet as have some
of the other folks you mentioned.
My suggestion would be to have an
informal, one time call to understand who the commiters are,
what they are trying to do and align at least high level
objectives and a working model. I remember Ken Saks back in EJB
3.1. Although he was the assigned specification lead, he really
did build consensus even though he didn't need to and treated
everyone that actually contributed equally even though some of
us were just independent consultants not even working for a
vendor. The same can be said of Nigel Deakin for JMS 2. Both
started the EG with having a brief group call followed by
individual, one-time one-on-one sessions/emails. It helped
enormously I think and established the social norms that will
likely need to evolve here to avoid hard/nasty lessons that may
effect the technology negatively.
Just my two cents. Easier said than
done, I know.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
P.S.: I'll ask Ed if he can join in
and try to help even through he can't sign any paperwork like
me. You should feel free to ask him too. I bet he'd be honored.
On 1/23/2020 4:01 PM, Greg Wilkins
wrote:
I'm very familiar with what a rough consensus
model is and it's the right decision model for ee4j
specifications and it's good to have many voices involved in
that.
But ultimately consensi don't just
materialise. You need leaders to seek consensus and to make
a call if it had been achieved or if more discussion is
needed. Otherwise it's too easy for some to just assume that
everybody agrees.
I'm cautious because the history of the
servlet spec is not a gentle one. There have been major
disagreements and the poor quality of aspects of the spec
today reflect that. Now I don't see any evidence of that in
the group now, but the history has made me very cautious.
I obviously don't really understand the
process that I'm supposedly leading.... So I'm going to have
to think about that.
Greg,
Consensus
doesn't mean that everyone is perfectly happy. :-)
Another example from MicroProfile... We recently decided
to move our use of the Jakarta EE 8 APIs to the next
release in June. It was originally scheduled for our Feb
release. Due to some edge cases (my words) with our
components, it was determined that this move to Jakarta EE
8 was just too much work to contain in the Feb release. I
argued against it until I was blue in the face. My
thought was that we could satisfy 95% of our customers
with a simple upgrade and then we can fix the edge cases
in our next release. I was overruled by the majority of
the team. It was not a consensus where everyone was
happy, but it was consensus in the sense that we did the
right thing for the overall project. We had a very good
discussion where all of ideas came out (both on the
mailing list and in our hangout calls). Overall, it was a
very healthy exchange of ideas.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
Greg Wilkins
<gregw@xxxxxxxxxxx>
To:
Kevin Sutter
<sutter@xxxxxxxxxx>
Cc:
EE4J PMC
Discussions <ee4j-pmc@xxxxxxxxxxx>
Date:
01/23/2020
14:15
Subject:
[EXTERNAL]
Re: [ee4j-pmc] Additional spec lead for servlet-api?
I have no idea how to reconcile
the concept of coming to a consensus vs all committers are
equal?
In the IETF model it is the
lead that determines if a rough consensus has been
achieved and thus allow progress to be merged. But if our
leads have no special powers and thus cannot rule that a
consensus has been achieved or not, then any subset of
committers can make changes without seeking consensus (as
has already happened).
I'm not advocating that leads
are architects, only that they should be gateways that can
only be passed if a consensus has been reached.
On Thu, 23 Jan 2020, 20:31
Kevin Sutter, <sutter@xxxxxxxxxx> wrote:
It was
decided from the very start of EE4J/Jakarta EE that we
would no longer have Specification Leads. Each Eclipse
Project needs at least one Project Lead. But, I have
stated over and over again that Project Leads do not
equalSpecification Leads. Full stop.
As far as the list of Committers. When the Servlet
Project was first proposed, there was
a list of proposed committers. We invited all of the past
expert group members. Plus, each Strategic Member of the
Jakarta EE has the ability to appoint
a committer representation on each Specification
Project. In
addition, there may have been some key industry
individuals that were invited to participate. Actually,
since the Spec Lead (Ed Burns) was no longer active on the
Project, that's how we ended up inviting you, Greg, and
Stuart to be co-Project Leads. And, that may have also
been where some of the "extra" Oracle reps came from.
TBH, I can't remember the exact process for every
Project. But, in the end, anybody could have (and some
did) challenge the make-up of the initial committer list
before the Project was approved.
(Also, just to explain this "appointment" process.. This
was put in place to support the Member organizations where
the current committer moves onto another job (either
inside or outside of the organization). I'll use IBM as
an example. Martin Mulholland was the JSR expert group
member from IBM. Martin moved onto another role right
about the time that these Specification Projects were
being proposed at Eclipse. Thus, we put Paul Nicolluci
down on the initial committer list instead of Martin.
Paul has been working on IBM's Web Container solution
maybe even longer than Martin did. In any case, this is
why the Member organizations need the ability to appoint a
committer to replace exiting committers and still stay
involved with the Project.)
As Project Leads, you do not have the power to determine
who will be or not be a committer. The set of committers
determine that via a vote. Any committer can nominate
another person as a committer, and then the committers can
vote on the person based on the stated merit. Similar to
what's happening with the Project Lead vote for Mark right
now.
I personally don't think you can have too many
committers. That normally means that you have a vibrant
community and you all help each other out. At
MicroProfile, we have 54
committers. Does it
get challenging at times to come to a consensus? Sure,
absolutely. Is it perfect? No. But, at the end of the
day, we have a better product. So, I think we have a good
example where having many diverse committers can work and
does work productively. The Servlet project needs to try
this model before claiming it doesn't work.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter:
@kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Reza Rahman
<reza_rahman@xxxxxxxxx>
To: EE4J PMC
Discussions <ee4j-pmc@xxxxxxxxxxx>, Greg
Wilkins <gregw@xxxxxxxxxxx>
Date: 01/23/2020
12:41
Subject: [EXTERNAL]
Re: [ee4j-pmc] Additional spec lead for servlet-api?
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
To be honest, I mostly agree with Greg here. While the JCP
specification lead model had flaws, at least we know for
sure it can work. The new model sounds good in theory but
no one really knows how it will work in practice. It is a
good idea to ease into the ideal view starting from what
we know can work in practice.
I too am a bit mystified with the whole previously unknown
and silent committers in pretty much all of the current
projects. I think some practical reconciliation is needed
for key specifications like Servlet to move forward
confidently.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an
individual community member and do not reflect the views
of my employer.
On 1/23/2020 12:44 PM, Greg Wilkins wrote:
I don't think we have "rouge actors" in the project and I
have no reason to doubt the good will of those involved.
The process issues I've complained about were all well
intentioned - just uncontrolled.
But I do think we have too many committers (13 I miss
counted) and to be honest I really don't know who most of
them are, or how they got to be committers. Most were
never active on previous servlet expert groups and most
are pretty quiet and rarely say anything. So I really
fear how the project is going to work if/when we get onto
some real evolution of the project. The thought that a
group of these unknown committers could have as much
influence of the future of the servlet-api as Mark,
Stuart, Bill and myself is a worry (or perhaps they'll do
something wonderful, but it's a risk).
I actually would prefer only 5 or 6 committers of those
who have a long history with developing the servlet-api,
but as that is not the case then I proposed the 3 co-leads
as a way to have some structure. If we only had 5 or 6
active committers, then that would not be necessary.
regards
On Thu, 23 Jan 2020 at 18:34, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
Greg,
while I do not see any problem having several project
leads, and while I think this is not something the EE4J
PMC shoud decide about as it is not a EE4J-specific
problem, I'd though like to propose a completely different
approach. Just as an idea.
In the Eclipse eco system, the role of "Review Team" is to
be fulfilled by committers, not by project leads.
If you have 15 committers, then you possibly have too much
committers which should be simple contributors instead;
you do not have too less project leads.
It is completely up to your project to decide all about
that, but maybe it would be best to simply turn committers
into contributors, and have the rest of the committers be
the "core review team" then?
-Markus
Von: ee4j-pmc-bounces@xxxxxxxxxxx[mailto:ee4j-pmc-bounces@xxxxxxxxxxx] Im Auftrag
von Greg Wilkins
Gesendet: Donnerstag, 23. Januar 2020 18:15
An: EE4J PMC Discussions
Betreff: Re: [ee4j-pmc] Additional spec lead for
servlet-api?
Paul et al,
I could not disagree more about the need for a "core
review team". Currently the servlet-api project has 15
committers and we have already had issues where a PR has
been made by one, review by another, merged all without
knowledge of the spec leads and in a few hours (which were
the middle of the night for both spec leads). We've even
had release candidates made in similar ways. To combat
this, we have said that all PRs need approval from a spec
lead - thus we have defacto created a core review team.
the proposal to include Mark as a co-lead exactly intended
to increase the "core review team".
I just do not believe that 15 equal committers can
collaborate productively without some structure. I don't
want the old single leader commits everything model, but
the 15 equal committers is too far the other way. We are
striving for a happy medium.
I'm not sure on what basis the vote should be stopped.
It's been proposed, if the vote gets up, then we have 3
leads. If enough people think it is a bad idea, then the
vote wont get up and we'll only have 2 leads.
regards
On Thu, 23 Jan 2020 at 18:00, Paul Nicolucci <pnicolucci@xxxxxxxxx> wrote:
Hi,
I also agree that 3 leads seems excessive when the primary
role of the lead is to be a guiding voice on process
rather than making decisions and having some sort of
special privilege within the project. If there are
specific reviews/work that are required within the Servlet
project that man/brain power is required for then some
threads should be started in the project in my opinion to
get input from the rest of the committers on the project
and allow them to offer a helping hand wherever necessary.
I think we need to get away from the concept of having a
"core review team" and be more transparent within the
individual projects.
Regards,
Paul Nicolucci
On Thu, Jan 23, 2020 at 10:19 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,
Though I voted for Mark, based on the fact he's very
active and experienced, I do agree with 3 Project Leads
being too much.
Perhaps in this case Greg might want to step down then?
Kind regards,
Arjan
On Thu, Jan 23, 2020 at 4:50 PM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
I agree with what Kevin said about a number of leads. One
lead is ideal, two is acceptable, more than two is too
many. I don’t have anything agains Mark, he is a great
project lead, but I think that in order to get him elected
someone needs to step out to keep a number of leads
reasonable.
I don’t agree with complete elimination of Project Lead
role. I see this situation as a consequence of
misunderstanding of what project lead role is. We should
work more on explaining EDP to committers and make it more
clear.
- Dmitry
On 23 Jan 2020, at 16:25, Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Yes, let's put it on the agenda. I don't think it is a big
problem. More a communication thing that we need to
continue doing for a while in order to get the thought of
a spec lead role to go away. After all, it is 20 years of
history we are competing with. It will take some time, but
we will get there :)
Ivar
On Thu, Jan 23, 2020 at 4:42 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
I guess I was too late with this input since I see that
the vote already started... :-)
Ivar,
Let's put this on our agenda for our next call. I'm
concerned that this proliferation of Project Leads can be
misconstrued as a requirement to make decisions for a
given Project. We need to emphasize that the Project
committers and community are key to making decisions. The
Project Leads should be considered "shephards" of the
process, not Specification Leads (as in the old JCP
definition). Even the title of this note thread seems to
imply "spec leads" vs "project leads". Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter:
@kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: "Kevin Sutter"
<sutter@xxxxxxxxxx>
To: EE4J PMC
Discussions <ee4j-pmc@xxxxxxxxxxx>
Date: 01/23/2020 08:10
Subject: [EXTERNAL] Re:
[ee4j-pmc] Additional spec lead for servlet-api?
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
Question... do you really need a third Project lead to
enable these wheels of progress? Remember, we do not
have Specification Leads like we did in the JCP days.
The Project Lead is used to help the project team follow
and adhere to the Eclipse processes. All committers on
the Project should have equal footing to enable progress
on the Specifications, APIs, and the TCK (if there is
one in the Servlet project). I would really question
why a third Project Lead is required.
A bit of background... I know from past experiences
both with Jakarta EE and MicroProfile that even two
Project Leads is questionable by Eclipse. But, we have
found two Project Leads to be useful to help even the
playing field. For example, with MicroProfile, myself
and John Clingan are co-Project Leads. We communicate
on a regular basis and we cover for each other when the
other can't do the Project Lead responsibilities due to
vacation or other work activities. We have never
entertained the thought of requiring a third Project
Lead. All of the MicroProfile committers chip in to
help with the various project responsibilities.
One bad example is the EE4J Platform Project. Here we
have six Project Leads. The reason is that when all of
these Projects were getting created for Jakarta EE, we
didn't want to spend the time to determine the proper
Project Leads. So, all of the lead organizations ante'd
up a person and we all became Project Leads. Again, I
know that Eclipse wasn't thrilled with this approach.
And, we should probably revisit this at some point.
So, going forward with nominating another Project Lead
is your project's choice. As Ivar mentioned, it is a
required vote among all of the committers on the Servlet
Project. I would just consider whether another Project
Lead is really necessary to accomplish what you are
looking for. Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter:
@kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Ivar Grimstad
<ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
To: EE4J PMC
Discussions <ee4j-pmc@xxxxxxxxxxx>
Date: 01/23/2020 00:46
Subject: [EXTERNAL] Re:
[ee4j-pmc] Additional spec lead for servlet-api?
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
Hi Greg,
You can propose a new project lead and start an election
among the committers using the committee tools on the
servlet project page https://projects.eclipse.org/projects/ee4j.servlet/developer
Ivar
On Thu, Jan 23, 2020, 08:21 Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
Hi PMC,
Stuart and I would like to add Mark Thomas as a third
co-lead in the servlet-spec project. Having the extra
man power and a third brain in the core review team
would grease the wheels of progress. What is the
process to make this happen?
regards
--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse
Foundation, Inc.
Eclipse
Foundation:
The Platform for Open Innovation and Collaboration
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member and do not represent the views of my employer.
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc