Re: Restore write access for all EG members?


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

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