Community
Participate
Working Groups
This ticket is for tracking discussion and work related to the authorization and authentication scheme used for Long Term Support (LTS).
Currently, we expect a few principle levels of authorization for Long Term Support (LTS): 1) Public, which currently is planned to have no access to the LTS forge 2) LTS regular/basic, which will have access to some LTS resources, but not all 3) LTS premium, which will have access to all LTS resources and 4) In addition, committers will have access to some elements of the LTS forge. Elements that will be authenticated and authorized include: a) LTS members-only downloads site b) LTS code repository c) LTS Hudson instance d) LTS Build servers In addition, we anticipate some premium LTS features may be: i) Bugzilla groups to keep bugs private to a given LTS member until they are fixed. ii) Potential for group authorization and authentication of LTS member private cloned code repositories. e.g. Company X wants some/all their employees to all have commit to a Company X specific code repository.
Increasing priority
More elements that will be A&A'd include: * A Nexus instance for LTS * A Nexus instance for a given company's private area/forge (within LTS) * If not encapsulated within Nexus, Orbit for LTS and potentially a company-specific instance of Orbit.
Also: Regarding #4, committer access, currently they are planned to have read-only access to git, but no access to binaries nor will they be able to run builds on the LTS build farm.
(In reply to comment #1) > Elements that will be authenticated and authorized include: > a) LTS members-only downloads site > b) LTS code repository > c) LTS Hudson instance > d) LTS Build servers Is this the only intended level of granularity? i.e. will regular Eclipse committers have uniform access within the LTS forge, or is their access to projects within the LTS forge restricted to only those projects they have access to in the public forge?
I believe since committers have read-only access to all projects in the community forge, read-only access to all projects in LTS isn't crazy. If we can do project-by-project without too much overhead it's worth considering. For maintenance committers this is even more interesting. There are two ways to approach it: 1) Everyone gets the minimum possible access. e.g. just the project they requested/work on. <= generally always a good idea, but much more work to administer. It may lead to frivolous requests. 2) Everyone gets the maximum access.<= obviously less work to administer, but scary from a code scrutiny perspective.
(In reply to comment #6) > I believe since committers have read-only access to all projects in the > community forge, read-only access to all projects in LTS isn't crazy. If we can > do project-by-project without too much overhead it's worth considering. I think that I understand what you mean, but... Clarification: *everybody* has read access to all projects. Each committer has read/write access to *some* projects.
I believe most of this, if not all, can/should be handled through LDAP groups. We should perhaps use the same LDAP service which supports eclipse.org, since there will be overlap in eclipse.org users and LTS users.
I agree. Using the same LDAP instance makes good sense. There should be a group for: a) access to binaries on a release by release basis (Juno, Kepler, L-whatever, etc.) b) read-only access to all code. We can adjust this later if we need it to be project by project read-only c) read-write access to a given company's repositories. i.e. a maintenance committer d) read-write access to the common/central LTS repositories. i.e. a maintenance integrator. Revisiting Wayne's comment to be sure of clarity, as I think we're thinking the same thing. Only committers have read-only access to LTS projects. The LTS common/central repositories aren't public. It has been said that committers should ask for access & be subject to a special LTS agreement rather than have it automatically granted. And company specific repositories can only be accessed by people the company designates. The maintenance integrator role is new as per our last discussion on this a ways back, but I believe it makes good sense. Once we're in agreement, I'll run it by the LTS IWG as part of the meeting on June 29th.
A few ideas building on the discussion so far. In LDAP, ... ou=LTS_basic <= people with LTS participant access. Can download binaries. They should *not* be able to access LTS source code. ou=LTS_premium <= people with LTS premium access, Can: a) download binaries b) read-only access to the central LTS repositories. ou=LTS_<company> <= people with a) read/write access to company specific LTS forge b) read/write access to bugs in the company bugzilla group c) d) access to company Hudson jobs. The company controls who's in this group by selecting ids from ou=Community. ou=LTS_<company>_admin <= the person or people who administers the list of who has access to that company's area. ou=LTS_integrator <= selected representatives with write access to central LTS repositories, LTS download site, and corresponding hudson jobs. In order to maintain privacy in the company specific areas, we'll want to use something like gerrit on the central repositories to enable the change control process. Otherwise integrators would need to use bugzilla to find out about potential updates. Also need to think about incentives for integrators so work is reasonably balanced across members.
I'm pretty sure we have this all figured out now. Reopen if something is missing.
Moving to the Working Groups section.
