There has been discussion that these should be three specifications under a single specification project under Jakarta Security. This restructuring review covers the relevant aspects to implement these changes.
Restructuring To-Do list
In order to implement the proposed changes, we need to complete the following:
EMO (ED) approval
EE4J PMC +1
Spec committee approval
Infrastructure changes
✓
4 of 4 checklist items completed
· Edited
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
There has been discussion that these should be three specifications under a single specification project under Jakarta Security. This restructuring review covers the relevant aspects to implement these changes.
Several questions came up about what happens under the infrastructure step:
Is the resulting specification project committee list the union of the 3 projects existing committers? This is the desired outcome according to the specification committee.
Are the Jenkins CICD jobs of the existing 3 projects going to be merged into the existing security project pipeline, or do the others need to be merged manually?
Just to clarify: the goal of this is to merge the ee4j.authentication and ee4j.authorization projects into ee4j.es, with the final list of committers on ee4j.es being the union of all 3 projects committers?
Collecting the committers should be fine from a technical perspective, but it seems odd to be 'forcing' committers onto a project as that seems like it violates the EDP, but perhaps that doesn't apply to restructures.
@wbeaton, should ee4j.authorization and ee4j.authentication be archived or 'deleted' as part of this?
Which leaves us with infrastructure questions:
What should happen to the mailing lists/forums for these projects? Normally we'd close them with an 'over there now' message.
Are there any downloads/archives that will need to be moved?
For project websites(if any) can they be redirected to the PMI, should they point at the 'archived' projects page or should they point at the ee4j.es project website?
For CI instances our normal process would be to simply shutdown the 'unwanted' instances, as we don't typically move things(that's mostly up the the projects). We can certainly hold off on that for a period of time to give the projects time to complete the moves(our RelEng team should be able to provide guidance for this)
Ideally it would be limited to the exact changes required(this issue has some of that but is perhaps more procedural/permissive), or at least discussion about the actual changes in a location that is more frequently patrolled by the IT team.
As we're preparing to close this ticket I see that there are still some open points here. @sstark88g can you please provide some feedback to questions posed by @webmaster in the previous comments:
merging the ee4j.authentication and ee4j.authorization projects into ee4j.es will result in the final list of committers on ee4j.es being the union of all 3 projects committers?
Are you ready to archive the authorization and authentication projects (and their related resources)?
What should happen to the mailing lists/forums for these projects? Normally we'd close them with an 'over there now' message.
Are there any downloads/archives that will need to be moved?
For project websites(if any) can they be redirected to the PMI, should they point at the 'archived' projects page or should they point at the ee4j.es project website?