Topics

Restore write access for all EG members?


Arjan Tijms
 

Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms


Will Hopkins
 

I plan to keep the spec and api repos locked down until we're done. I've reviewed all the pending PRs for spec and api and merged, commented on, or closed them.

We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Ivar Grimstad
 



On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


--

Java Champion, JCP EC/EG Member, JUG Leader


Will Hopkins
 

First of all, I'd like to say that I understand and appreciate the tremendous contributions from the EG and all contributors. I especially appreciate Arjan's contributions -- my understanding is that he contributed most of the original code, and he's contributed a great deal to the spec itself.

I would also like to acknowledge that I am new to the business of being a spec lead, and that I am new to this JSR in particular, having become spec lead after much of the work to define the APIs and build the RI had already been done. So there may be aspects of the spec lead role that I'm misinterpreting, or don't fully appreciate, and there are definitely aspects of JSR-375 that I don't understand as well as most of you.

That said, it's my understanding that I am ultimately responsible for delivering the spec, the API, the RI, and the TCK. I'm responsible for meeting the schedule, and for the quality of the resulting deliverables. While I will always strive for consensus and agreement, it's also my understanding that I have both the responsibility, and the authority, to make the final decision on any question affecting the technical content of the JSR.

In my experience, it's necessary to institute change control on any project that is nearing completion; to do otherwise is to invite disruption, churn, and instability. This is not a question of trust, or of enabling contributions from a diverse group. What worked well early in the JSR's history won't necessarily work well as we try to complete it. It's true that commits can be rolled back, but that's an inefficient -- and potentially contentious -- way to do change control. I'd like to see things discussed and agreed before a change is committed, rather than after.

I'm mindful of the potential for me to become a bottleneck if I have to approve every change, and I'll make every effort to ensure that doesn't happen. Ultimately, while this may slow things down slightly, it's a pretty small change from the existing process -- people were already submitting PRs, the only change is who approves them -- and it will be a net win if it keeps the code stable and moving in the right direction.

One last point -- I'm not sure exactly what the rules are for repos under the javaee organization at GitHub, but I believe that all commits must be done via PR, must be approved by the spec lead, or a designate who is a member of the javaee organization, and may also be made contingent on passing some suite of tests. So the process we're adopting now is pretty close to what we'll see when the repos are migrated.

Best Regards,

Will


On 05/31/2017 08:08 AM, Ivar Grimstad wrote:


On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

--

Java Champion, JCP EC/EG Member, JUG Leader


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


reza_rahman <reza_rahman@...>
 

I agree ultimately you should do what you are truly comfortable with as specification lead (within reason of course). If you had any general questions, Bill and Linda could provide guidance.

-------- Original message --------
From: Will Hopkins <will.hopkins@...>
Date: 5/31/17 4:54 PM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: Re: [javaee-security-spec] Restore write access for all EG members?

First of all, I'd like to say that I understand and appreciate the tremendous contributions from the EG and all contributors. I especially appreciate Arjan's contributions -- my understanding is that he contributed most of the original code, and he's contributed a great deal to the spec itself.

I would also like to acknowledge that I am new to the business of being a spec lead, and that I am new to this JSR in particular, having become spec lead after much of the work to define the APIs and build the RI had already been done. So there may be aspects of the spec lead role that I'm misinterpreting, or don't fully appreciate, and there are definitely aspects of JSR-375 that I don't understand as well as most of you.

That said, it's my understanding that I am ultimately responsible for delivering the spec, the API, the RI, and the TCK. I'm responsible for meeting the schedule, and for the quality of the resulting deliverables. While I will always strive for consensus and agreement, it's also my understanding that I have both the responsibility, and the authority, to make the final decision on any question affecting the technical content of the JSR.

In my experience, it's necessary to institute change control on any project that is nearing completion; to do otherwise is to invite disruption, churn, and instability. This is not a question of trust, or of enabling contributions from a diverse group. What worked well early in the JSR's history won't necessarily work well as we try to complete it. It's true that commits can be rolled back, but that's an inefficient -- and potentially contentious -- way to do change control. I'd like to see things discussed and agreed before a change is committed, rather than after.

I'm mindful of the potential for me to become a bottleneck if I have to approve every change, and I'll make every effort to ensure that doesn't happen. Ultimately, while this may slow things down slightly, it's a pretty small change from the existing process -- people were already submitting PRs, the only change is who approves them -- and it will be a net win if it keeps the code stable and moving in the right direction.

One last point -- I'm not sure exactly what the rules are for repos under the javaee organization at GitHub, but I believe that all commits must be done via PR, must be approved by the spec lead, or a designate who is a member of the javaee organization, and may also be made contingent on passing some suite of tests. So the process we're adopting now is pretty close to what we'll see when the repos are migrated.

Best Regards,

Will


On 05/31/2017 08:08 AM, Ivar Grimstad wrote:


On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

--

Java Champion, JCP EC/EG Member, JUG Leader


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi,

What can I say? It would have been just as easy to announce to the group that the repo was effectively locked until further notice while preparing the PRD. You can additionally always take a note of the revision number to see what the exact version for the PRD is, or create a tag even.

That's exactly what Ed Burns and Manfred Riem did for JSF and everyone kept to that. Actually revoking the access, well intended or not, is IMHO not the right way to go forward with this.

It may be work to revert, but it's also work to let you be the bottleneck. As for the cost, it's generally known that an optimistic lock is cheaper than a pessimistic lock. Assuming that there's surely going to be reverting done is a pessimistic lock, and I'm sure you didn't intent it to be but almost by definition a pessimistic lock comes across as, well, pessimistic.

There's an amount of mundane work to be done, like moving things to the agreed javax.security.enterprise package. The PR for that can be immediately approved after quick review by basically any experienced EG member. This also makes it much easier to start the next PR right away and minimises the chances of merge conflicts.

The suite of tests is in the /test folder here https://github.com/javaee-security-spec/soteria/tree/master/test

I run them prior to every change and commit, and since I'm only human I could of course make a mistake and run them against the wrong version or something like that, so there's a CI job as well that also runs the entire test suite.

Kind regards,
Arjan Tijms




On Wed, May 31, 2017 at 10:54 PM, Will Hopkins <will.hopkins@...> wrote:
First of all, I'd like to say that I understand and appreciate the tremendous contributions from the EG and all contributors. I especially appreciate Arjan's contributions -- my understanding is that he contributed most of the original code, and he's contributed a great deal to the spec itself.

I would also like to acknowledge that I am new to the business of being a spec lead, and that I am new to this JSR in particular, having become spec lead after much of the work to define the APIs and build the RI had already been done. So there may be aspects of the spec lead role that I'm misinterpreting, or don't fully appreciate, and there are definitely aspects of JSR-375 that I don't understand as well as most of you.

That said, it's my understanding that I am ultimately responsible for delivering the spec, the API, the RI, and the TCK. I'm responsible for meeting the schedule, and for the quality of the resulting deliverables. While I will always strive for consensus and agreement, it's also my understanding that I have both the responsibility, and the authority, to make the final decision on any question affecting the technical content of the JSR.

In my experience, it's necessary to institute change control on any project that is nearing completion; to do otherwise is to invite disruption, churn, and instability. This is not a question of trust, or of enabling contributions from a diverse group. What worked well early in the JSR's history won't necessarily work well as we try to complete it. It's true that commits can be rolled back, but that's an inefficient -- and potentially contentious -- way to do change control. I'd like to see things discussed and agreed before a change is committed, rather than after.

I'm mindful of the potential for me to become a bottleneck if I have to approve every change, and I'll make every effort to ensure that doesn't happen. Ultimately, while this may slow things down slightly, it's a pretty small change from the existing process -- people were already submitting PRs, the only change is who approves them -- and it will be a net win if it keeps the code stable and moving in the right direction.

One last point -- I'm not sure exactly what the rules are for repos under the javaee organization at GitHub, but I believe that all commits must be done via PR, must be approved by the spec lead, or a designate who is a member of the javaee organization, and may also be made contingent on passing some suite of tests. So the process we're adopting now is pretty close to what we'll see when the repos are migrated.

Best Regards,

Will



On 05/31/2017 08:08 AM, Ivar Grimstad wrote:


On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

--

Java Champion, JCP EC/EG Member, JUG Leader


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Werner Keil
 

See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner


Rudy De Busscher
 

Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner



Arjan Tijms
 

For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms



Ivar Grimstad
 

One comment regarding transfer of the repos to the JavaEE organization. Keep in mind that GitHub does not currently support sub-organizations, so all our repos will be spread out there.

For MVC we have chosen to only have the spec (doc+api) in the Java EE organization as a read-only mirror. All work is done in the mvc-spec GitHub organization where we have the spec, ri and tck as well as proposals and samples all gathered together.

Ivar

On Thu, Jun 1, 2017 at 7:13 AM Rudy De Busscher <rdebusscher@...> wrote:
Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner


--

Java Champion, JCP EC/EG Member, JUG Leader


Arjan Tijms
 

On Thu, Jun 1, 2017 at 7:47 AM, Ivar Grimstad <ivar.grimstad@...> wrote:
One comment regarding transfer of the repos to the JavaEE organization. Keep in mind that GitHub does not currently support sub-organizations, so all our repos will be spread out there.

That's unfortunate indeed. A very good hyphen naming scheme could somewhat alleviate that, but it's still not as nice as a real sub-org. E.g.


(api-api looks a bit weird here)

 
For MVC we have chosen to only have the spec (doc+api) in the Java EE organization as a read-only mirror. All work is done in the mvc-spec GitHub organization where we have the spec, ri and tck as well as proposals and samples all gathered together.

Something to think about for sure.

Thanks!

Kind regards,
Arjan Tijms

 

Ivar

On Thu, Jun 1, 2017 at 7:13 AM Rudy De Busscher <rdebusscher@...> wrote:
Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner


--

Java Champion, JCP EC/EG Member, JUG Leader



Rudy De Busscher
 

Arjan,

Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api.
I had the impression from the communication by Will that Soteria (as it is the RI) was also locked.

Another clone will make this only more complicated, the original repositories need to be in maintained good shape.

Rudy


On 1 June 2017 at 07:45, Arjan Tijms <arjan.tijms@...> wrote:
For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms




Will Hopkins
 

I think this is getting blown out of proportion. With the exception of a small change to who can approve a PR, nothing has changed.

Anybody who wants to submit a PR against security-spec or security-api can still do so. All PRs will be reviewed in a timely fashion, and potentially committed. This is not materially different from what the situation was two weeks ago, except that the list of approvers is shorter than it was. It is not the case that we are no longer accepting commits, and there is no need to create new repos to do work.

Also, as others have noted, the soteria repo is still open to all, precisely because there is more work going on there, and because the RI is not as "public" as the API -- it's not documented as part of the spec -- and therefore has more capacity to absorb changes at this point in the process.

I did not expect this to be such a controversial change -- in my experience, it's a pretty typical practice used to keep code stable as a release approaches, and I did say, when I announced I was locking the repos, that I intended to keep the access limited after the PRD was published (although, in hindsight, I probably did not state it as clearly as I should have).

I'll give some thought to opening this back up, but I want to re-iterate the basic concerns here:
  • The spec and the API need stability going forward. That doesn't mean they can't change, but changes need to be well-considered and discussed with the EG before going in. Our date to produce a final draft is less than one month away, given the lead time the JCP requires to publish.
  • Along the same lines, I need to be OK with the changes that are going in. This may feel unfair to some -- I'm the new guy, and wasn't around while most of the original work was going on. Many of you have greater expertise in particular areas of EE than I do. But that is the spec lead's job, and I think the perspective I bring from an app server vendor POV is important if JSR-375 is to be successful. As well, there is a "tail" of work for the Oracle GlassFish and TCK teams that emanates from changes to the spec and the API (and, for that matter, from the RI). That tail is invisible to the EG, but it impacts our ability to deliver the JSR on time. It's something that, as spec lead, I need to be mindful of.
  • I disagree with the idea that it's just as easy to roll back a commit as it is to institute change control on incoming PRs. The technical effort may be similar to merging a new change (for both simple and complex cases), but in my view there's a higher bar when arguing to roll back a change than there is when arguing that a change shouldn't go in. It also creates more code churn to commit, then roll back, changes that shouldn't go in.
Thanks for your patience. I'm going to give this some thought, and talk to a few people privately, and I may open things back up, at least to some degree.

Meanwhile, please feel free to submit PRs against any of the repos for changes you think are needed. The soteria repo is still wide open, and PRs for the spec and API repos will be reviewed promptly.

Thanks,

Will

P.S. Regarding the naming scheme for our repos under the javaee org, they will all be prefixed by "security-", so that they are easy to find. Two of the repos already have the "security-" prefix. The soteria repo will be renamed to "security-soteria".


On 06/01/2017 03:36 AM, Rudy De Busscher wrote:
Arjan,

Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api.
I had the impression from the communication by Will that Soteria (as it is the RI) was also locked.

Another clone will make this only more complicated, the original repositories need to be in maintained good shape.

Rudy


On 1 June 2017 at 07:45, Arjan Tijms <arjan.tijms@...> wrote:
For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

The names of the JSR-375 repos under the javaee organization will be:

github.com/javaee/security-api
github.com/javaee/security-soteria
github.com/javaee/security-spec

Will

On 06/01/2017 01:56 AM, Arjan Tijms wrote:
On Thu, Jun 1, 2017 at 7:47 AM, Ivar Grimstad <ivar.grimstad@...> wrote:
One comment regarding transfer of the repos to the JavaEE organization. Keep in mind that GitHub does not currently support sub-organizations, so all our repos will be spread out there.

That's unfortunate indeed. A very good hyphen naming scheme could somewhat alleviate that, but it's still not as nice as a real sub-org. E.g.


(api-api looks a bit weird here)

 
For MVC we have chosen to only have the spec (doc+api) in the Java EE organization as a read-only mirror. All work is done in the mvc-spec GitHub organization where we have the spec, ri and tck as well as proposals and samples all gathered together.

Something to think about for sure.

Thanks!

Kind regards,
Arjan Tijms

 

Ivar

On Thu, Jun 1, 2017 at 7:13 AM Rudy De Busscher <rdebusscher@...> wrote:
Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner

--

Java Champion, JCP EC/EG Member, JUG Leader



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi,

On Thu, Jun 1, 2017 at 6:46 PM, Will Hopkins <will.hopkins@...> wrote:
I think this is getting blown out of proportion. With the exception of a small change to who can approve a PR, nothing has changed.

I personally think this is fundamental though for the perception of the JSR.

Java EE JSRs have been opening up more over time and as a result became more successful. This cycle, JSF and Java EE Security have been particularly open and have been a great success.

It's not in either my or the other experienced EG members best interest either to make unwarranted and undiscussed changes. Trust and community engagement are important things and I feel that's currently not optimal this way. I'm absolutely sure that people like Werner, Ivar, Rudy and myself are just as careful as you would be.

You also mentioned wanting to close the Soteria RI, but that's IMHO certainly not needed. To the best of my knowledge, even the more conservative specs have not closed the implementation project for their regular committers. The Mojarra project, where I'm a committer as well, certainly did not do this.

 
Also, as others have noted, the soteria repo is still open to all, precisely because there is more work going on there, and because the RI is not as "public" as the API -- it's not documented as part of the spec -- and therefore has more capacity to absorb changes at this point in the process.

Indeed, it's still open, and really should stay open. There are lots of things that need to be done still that have no effect on the spec proper, not in the least expanding the test suite.

 

I did not expect this to be such a controversial change -- in my experience, it's a pretty typical practice used to keep code stable as a release approaches, and I did say, when I announced I was locking the repos, that I intended to keep the access limited after the PRD was published (although, in hindsight, I probably did not state it as clearly as I should have).

I'll give some thought to opening this back up, but I want to re-iterate the basic concerns here:
  • The spec and the API need stability going forward. That doesn't mean they can't change, but changes need to be well-considered and discussed with the EG before going in.
Absolutely, and that is I think the understanding of everyone. We're all experienced and dedicated people here, so taking myself as example, there really should be no need to assume I would suddenly do a large undiscussed commit.

 
  • Along the same lines, I need to be OK with the changes that are going in. This may feel unfair to some -- I'm the new guy, and wasn't around while most of the original work was going on. Many of you have greater expertise in particular areas of EE than I do. But that is the spec lead's job, and I think the perspective I bring from an app server vendor POV is important if JSR-375 is to be successful.

I think nobody is saying that the app server vendor POV is not important, of course it is. But don't forget that I work for an app server vendor as well, so your concern is the same as my concern ;)

Ideally, in my vision of the JCP process, there should be representatives from every POV in the EG. The library vendor, the app server vendor, the consultant, the "regular" application developer, the big enterprise, the smaller company and what have you. But the spec lead should not directly be representing any of these POVs, but ideally, in my opinion, should be balancing the concerns of all of those.


  • As well, there is a "tail" of work for the Oracle GlassFish and TCK teams that emanates from changes to the spec and the API (and, for that matter, from the RI). That tail is invisible to the EG, but it impacts our ability to deliver the JSR on time. It's something that, as spec lead, I need to be mindful of.
I know this all too well indeed, as we've recently finished the JSF spec in which I had a major role.

As far as the TCK is concerned, I'd really like to contribute to that as well in whatever shape or form (I'll start a separate thread for this).

 
  • I disagree with the idea that it's just as easy to roll back a commit as it is to institute change control on incoming PRs. The technical effort may be similar to merging a new change (for both simple and complex cases), but in my view there's a higher bar when arguing to roll back a change than there is when arguing that a change shouldn't go in. It also creates more code churn to commit, then roll back, changes that shouldn't go in.

The crux of the problem here as I see it, is that the assumption is then that there are going to be many such reverts.

My assumption is that there won't be much if any such revert needed, as we're all experienced and responsible people here. If a revert would ever be needed since it broke something, then I'm sure such a revert might just as well have been needed if it happened via an approved PR.

We didn't do any rash commits when the spec lead was no where near in sight and we still had all the time in the world. For example, I did *a lot* of work for the authorization rules story last July and August, but I didn't put that in the spec since I felt not enough EG feedback had been given after I presented it.

 
  • Thanks for your patience. I'm going to give this some thought, and talk to a few people privately, and I may open things back up, at least to some degree.

Okay, thanks in advance for that :)

 
P.S. Regarding the naming scheme for our repos under the javaee org, they will all be prefixed by "security-", so that they are easy to find. Two of the repos already have the "security-" prefix. The soteria repo will be renamed to "security-soteria".

Sounds good!

Kind regards,
Arjan Tijms

 



On 06/01/2017 03:36 AM, Rudy De Busscher wrote:
Arjan,

Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api.
I had the impression from the communication by Will that Soteria (as it is the RI) was also locked.

Another clone will make this only more complicated, the original repositories need to be in maintained good shape.

Rudy


On 1 June 2017 at 07:45, Arjan Tijms <arjan.tijms@...> wrote:
For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Arjan Tijms
 

Hi,

After having a talk with Will over this and giving it some more thoughts I think it's probably better to let Will finalise the spec in a way he feels most comfortable with.

Probably most of the confusion about making commits arose from the 2 methods that were added to the SecurityContext, namely the method for determining access to web resources, and the one for getting all roles. From my point of view this was added even before the EDR was accepted, so that would normally be absolutely acceptable, but for Will it was at a point that everything was expected to be "basically done" (with only what's already there left to be evaluated cleaned/up).

Those are different points of views, and given more time I'm sure we could have come to a better understanding than we already reached, but that time is not there now. So in the interest of getting things done at all, I'm now agreeing with Reza to let things be done as Will feels most comfortable with ;)

So, let's round off the other threads that are open and make sure we can proceed to the next stage of the JCP process soon.

Kind regards,
Arjan Tijms