Re: 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.
On 05/31/2017 08:08 AM, Ivar Grimstad wrote:
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803