Re: Restore write access for all EG members?


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


Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.