[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-pmc] Additional spec lead for servlet-api?
|
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
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
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.
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.
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?
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
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 :)
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
--
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
--
_______________________________________________
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