Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] PMC Minutes

David,

 

thank you. Reads promising. :-)

 

FYI: Since January I am actively recruiting volunteers for JAX-RS and other projects. This is invisible to anybody (including the PMC and the EF), and it is a real lot of unpaid work, but it does pay off. Two active contributors on JAX-RS are the result of that so far, and I have people at hand just waiting to volunteer on JAXB and Jersey. More might follow later after I did my planned "recruitment presentations" at JavaForumStuttgart and EclipseCon Europe in July and October. I also took new committers in the boat, and I was the one driving the management process of getting the planned committers in the status of a actual Github committer (with Wayne's kind help). I do not want credit for that nor show-off. I just wanted to say that there already are several people doing valueable management work behind the scenes (like Christian Kalthepoth greatly improved the CI and Github settings) outside of the PMC / EF official structures, so at least in some projects the actual drivers are not (or not solely) the current project leads, and these people (including me) would be more than happy to simply get asked instead of getting top-down governed. I do not see that any real issue would exist that hinders the PMC from accepting input from such people, neither legally nor organizational or capacitive.

 

-Markus

 

 

From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of David Blevins
Sent: Donnerstag, 17. Mai 2018 20:07
To: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] PMC Minutes

 

Let me state I agree with you on many points and my email was an attempt to give you the information I had, not my personal perspective.  I'm on 2 of the 3 committees and the PMC, so I have a lot of visibility and attempting to share because there's a general lack of visibility.  I certainly don't want the impression that absolutely all information I give is my personal vision for the future, so I won't counter any of your points because it would give the impression I'm the one that needs to be convinced.

 

For Java EE Security EG for example, I reached out as you described and solicited participants on list and brought them to Eclipse.  I didn't have the bandwidth to do that for all specifications.  The doors are not closed yet either.  We're still early stages on everything, so it would be wrong to assume if something isn't done it's because of lack of will.  It's just lack of time.

 

I'll also reiterate, the roadmap item is an attempt to do exactly what you describe.  There are a lot of committees who meet privately.  The risk of them attempting to define roadmap is high.  The PMC was asked for a roadmap by the Steering Committee.  We said, this should come from the community.  Those were the words we used verbally.  What was written down in the minutes was just a short note.

 

This is whole thing is a couple days old.  Let's agree not to get too hung up on the minutes and focus on what the goal is, to get the communities active in some form of bottom up roadmap.  Even if it is temporary it's better than having nothing there.  We need some direction coming bottom up to begin adding balance.

 

I'm going to turn my attention to the JMS project where I've committed my time.  If you want to help with JAX-RS or any other group, that'd be great.

 

On May 17, 2018, at 8:57 AM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

 

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

 


Back to the top