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

There are many parts of the Eclipse Platform project that are stable and don't change from release to release. This is a pretty normal thing, I think.

It all depends on why it's stagnating. If it's the case that the technology has matured to the point where it doesn't need any additional work, then having some subset of your project code not evolving seems pretty reasonable to me.

Wayne

On 04/28/2012 09:07 AM, Glyn Normington wrote:
It's a good point about Blueprint stagnating. At least having a separate committer list meant this became explicit. If we had one list of Gemini committers, then projects could die without it really being obvious from the outside.

Regards,
Glyn

On 28 Apr 2012, at 00:59, michael keith wrote:

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.

-Mike

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?

Regards,
Glyn



_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc

_______________________________________________ rt-pmc mailing list rt-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/rt-pmc

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects