[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Gemini Subprojects

Sorry for being late to this discussion. Have been travelling for the last few weeks and apparently failing miserably at keeping up with email and meetings...

We went through this whole discussion when Gemini was first formed, and as a result of many of the limitations we ended up with separate subprojects. I agree that it would be great if the ACL committer lists, IP logs, separate release plans, release reviews and schedules, etc. etc. were more flexible in the project, but when it comes down to it, and you have multiple different release artifacts for multiple different technologies, and the list of things that are different between them gets so high that there is not much in common, you kind of end up concluding that they really are different projects. In the case of Gemini Blueprint, I think it's fair to say that the problem wasn't that Blueprint committers were separate from the rest of the Gemini committers, but that Blueprint was basically stagnating and inactive as a project, resulting in a void of active committers.


On 27/04/2012 6:20 AM, Glyn Normington wrote:
At the last RT PMC call there was discussion of Gemini's subproject structure. Recently, one of the subprojects temporarily had no committers and the thought was expressed on the call that this could perhaps be avoided in future by amalgamating the Gemini subproject committers into a single ACL. Presumably this would require amalgamating the subprojects into one.

I spoke to Mike Keith about this and it seems that it is necessary to keep the subproject structure so that individual subprojects can be released independently of each other (which is essential). For example, the subproject structure enables IP logs to be managed and approved separately.

So is the conclusion that we can't amalgamate the ACLs without losing the ability to release subprojects independently of each other?


rt-pmc mailing list