| Summary: | Add permissions for Gemini developers | ||
|---|---|---|---|
| Product: | Community | Reporter: | Michael Keith <michael.keith> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | juergen.kissner, krum.tsvetkov, milesg78, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Michael Keith
As far as I can tell, none of these folks are committers on rt.gemini. Why do they need access?(Perhaps the better question is: what are you trying to do?) -M. The problem is that Gemini is really just a conglomerate of its subprojects, and these folks are committers on the subprojects: Gemini JPA, Gemini DBAccess, Gemini Web, Gemini Management, Gemini Blueprint and Gemini Naming. We want to have some shared resources at the Gemini level, such as a P2 repo, but there is not really much that the Gemini container project does, apart from some planned shared demos, repos and resources. I am trying to give someone from each of the subprojects permissions to access and set up the repos, etc, but didn't want to go through making them formal committers since there is not really much to commit to. Does that make sense? So the best path forward here is for you to elect these folks to the Gemini 'top' level project. That will give them access to the Gemini downloads area(in addition to their sub-project access), and will make management for you (and I) much easier. I'm resolving as 'worksforme' as this is part of our broader push to eliminate permission 'exceptions' and apply a standardized group layout. -M. |