Re: [ee4j-pmc] PMC Minutes

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Markus,
Some of your points make sense to me,
but not the first couple...  Each EE4J subproject can not determine
their own direction, irrespective of the platform.  We can not allow
the 40 or so subprojects to do their "own thing" without some
regard to the overall direction of Jakarta EE and EE4J.  That would
be a disaster and basically end anything even semi-related to Java EE.
 We can not let anarchy rule.  Maybe this isn't what you were
saying, but that's how I read it...

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:      
 "Markus KARG"
<markus@xxxxxxxxxxxxxxx>
To:      
 "'EE4J PMC Discussions'"
<ee4j-pmc@xxxxxxxxxxx>
Date:      
 05/17/2018 10:57 AM
Subject:    
   Re: [ee4j-pmc]
PMC Minutes
Sent by:    
   ee4j-pmc-bounces@xxxxxxxxxxx

---

David,
 
I need to disagree with virtually
all you told me so far. Starting with "Crocodile tastes like Chicken."
;-)
 
Joking aside, I simply have
a different vision how to set up EE4J's future, and I do not see which
legal or scale issues stop us from the following:
 
- There is no such thing
like "the future direction of EE4J" as all EE4J subprojects are
independent entities.
- Whether or not EE4J subprojects
like to participate in a common policy is up to their committers.
- If the EE4J subproject
committers like to define a common policy, it is up to them to set up a
common discussion platform with the help of the EF and the PMC.
- Send an email to all JCP
EGs (the addresses are public) and ask the EG members to contribute to
EE4J projects. No need to ask the JCP for addresses, so no break of GDPR.
- Send an email to all JCP
EGs (the addresses are public) and ask the EG members to become Jakarta
WG members. No need to ask the JCP for addresses, so no break of GDPR.
- Send an email to all EE4J
project mailing lists and ask the committers whatever you wanted to ask
the current project leads.
- Send an email to all EE4J
project mailing lists and ask the committers to vote for new committers
immediately to get frequent contributors upgraded ASAP.
- Send an email to all EE4J
project mailing lists and ask the committers to vote for new project leads,
replacing the initial (non-elected) ones.
- Prune all EE4J projects
from inactive committers and non-elected project leads.
- Do not come up with anything
before asked by a committer. I do not see a real need to discuss a lot
of issues the PMC actually discusses. Be more relaxed. EE4J will be a success
once more committers get active, they will come up with ideas, and the
PMC can then simply implement those ideas instead of upfront trying to
set a direction that might be totally wrong. The committers will one day
have an idea how to replace the JCP EGs and until then simply the committers
do their work: What they come up with IS the specification.
 
That way you will get a much
more democratic basis in EE4J. The priority of getting EE4J set up democratic
is of higher priority than simply having some progress in an arbitrary
direction.
 
-Markus
 
 
From: ee4j-pmc-bounces@xxxxxxxxxxx
[mailto:ee4j-pmc-bounces@xxxxxxxxxxx]
On Behalf Of David Blevins
Sent: Mittwoch, 16. Mai 2018 00:31
To: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] PMC Minutes
 
On May 15, 2018, at 2:02 PM, Markus
KARG <markus@xxxxxxxxxxxxxxx>
wrote:
 
I need to say that asking
only the project leads will not really bear a bottom-up result
 
The intent is bottom up, truly.
 Or as best as we can get with our non-existent specification process,
incomplete projects, no clear definition of what replaces an Expert Group
or how it should work, and still no legal rights to the javax namespace
and all the complications that brings.  That "best" would
be pretty low quality and non-permanent at this point in time, but there
is a strong desire to find some way to get people engaged despite the very
obvious obstacles.
 
The intent is to take a baby steps
forward because if we don't the result will be that everything will be
waiting on everything.  I.e. the goal is anything but a deadlock,
which is what we have.  It isn't clear how to untangle all of this
so any correspondence should be read with the perspective all steps are
temporary and we're pulling at strings in a knot.
 
The general desire:
 
 - Start getting some technical
direction
 - Have that come from the
projects
 - Specification Committee
would just dictate process (JCP-like) not technical direction
 
Some of the obstacles:
 
 - We can't legally take contributions
yet, because we don't legally own javax.* in any form nor do we have patent
rights to any of the specifications
 - We already know the standard
Eclipse Contributor Agreement doesn't provide enough rights to support
a standards process, so any ideas we discuss now in the projects could
be legally questionable in the future.
 - We've only had two Specification
Committee meetings (2 hours total) and are gaining consensus that group
shouldn't be setting technical direction and it should come from whatever
replaces Expert Groups.  More time needed for that to get more firm
and it's clear as you say the groups we do have are barely enough to seed
the future "Expert Group" regardless.
 - There've been over 250
participants in the various EE-related Expert Groups in the last 18 years,
which presents primarily a scale issue and more recently a legal issue.
 The scale issue is Eclipse has never onboarded so many at once and
is already overwhelmed.  The second is the JCP/Oracle has no legal
rights to give the contact information for 250 people to Eclipse given
the new GDPR laws.
 
The results make things hard.  This
email is as imperfect as the situation, so full of holes and I haven't
listed everyone's thoughts on how to overcome the obstacles.  There
are many, but instead I'll just encourage people here to write some.  It
definitely won't hurt.
 
On the technical direction, ideally
that's something that can be done in the coming weeks (not days) and to
the best we can reflect people's thoughts.  Ideally we can be comfortable
with the unclear rules/lines and use this as an exercise to start inching
towards some clear rules/lines.  I think at minimum something like
JSR description is what we need.
 
If someone wants to grab that and
take a stab at filtering out the parts that wouldn't apply or filing in
anything new we might want to ask of future specifications, that would
be very helpful.
 
Goal is to have a basic template
and hand it to all the spec projects and say "fill this in to the
best of your ability."  I should probably start a new thread,
but ideally we'd have the template ideas by next Tuesday.  Not spend
too long on what it should be, then give a couple weeks to the projects
to fill it in.  That won't be perfect, but I suspect it would be a
considerable help in the efforts to move the specification process definition
forward.
 
-David
 
 
 
 
 
 
 
 
 
 
 _______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc