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