[
https://issues.apache.org/jira/browse/WHIMSY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853723#comment-16853723
]
Chris Lambertus commented on WHIMSY-270:
----------------------------------------
I agree [~sebb]. I am sure they chose ou=auth because it simply wasn't
considered to make them a pseudo-project, or they predated the current
owner/member LDAP tooling in whimsy. For all intents and purposes, I believe
the entire project/pmc tooling workflow should be the same for non-PMCs, since
it makes access to things like git and authentication workflow fit a standard
model instead of being in an outlier ou=auth group.
I want to avoid conflating the issue of non-PMCs vs other entities in ou=auth.
The majority (entirety?) of what's in ou=auth is svnauth for special cases.
This does not need to change. The only thing that needs to change is that auth
contexts for Projects (eg, the 10 listed in
[https://whimsy.apache.org/roster/nonpmc/)] need to happen as ou=project
groups. If a nonPMC project needs special case ou=auth outside of that, we
should rename those entries to $project-purpose to not conflict with the
ou=project ldap group name.
How are the 10 listed in the nonpmc roster differentiated from the other groups
in ou=auth? Does that all come from cross-referencing of committee-info.txt?
> non-PMC groups need to be treated as projects
> ---------------------------------------------
>
> Key: WHIMSY-270
> URL: https://issues.apache.org/jira/browse/WHIMSY-270
> Project: Whimsy
> Issue Type: New Feature
> Reporter: Chris Lambertus
> Priority: Major
>
> For groups such as D&I or others under
> https://whimsy.apache.org/roster/nonpmc/ there should be the ability to
> "press the button" to create and maintain the LDAP groups under ou=project.
> This will provide the following benefits:
> - allow LDAP management of the nonPMC
> - allow self-service github repo creation
> - allow proper github authorization for repos
> I am not aware of any downsides for this approach. I have not reviewed the
> code, but I am hoping it would be fairly trivial to implement, and would
> quickly unblock INFRA-18453.
> The current state of affairs would require infra to manually create and
> populate the LDAP group for D&I, which we'd prefer to avoid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
