The Planning Council has evolved to be basically focused on the release train. At the moment, the other forges haven't really expressed an interest in doing their own. It is at least possible that they may have an interest in joining the existing one. So at the moment, I would say that the question is moot.
If it becomes clear in the future that separate Planning Councils would be useful, we will adapt the development process accordingly. I would prefer to wait until we actually have a tangible use case in front of us before doing so.
Hi Wayne,
I see how a single AC makes sense, but a single PC ?
Donât the forges other than eclipse.org have very different requirements for ârelease trainâ and âplanningâ ?
If not then I guess Iâm a bit missing the point on why those forges exist in the first place, could you explain ?
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect â Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of
Wayne Beaton
Sent: Friday, April 19, 2013 10:18 PM
To: eclipse.org-architecture-council
Subject: [eclipse.org-architecture-council] Multiple forges at the Eclipse Foundation
While entering a new bug for mentors, it occurred to me that the relationship between the Eclipse Architecture Council and the various forges hasn't been fully discussed.
By way of background, the Eclipse Foundation has branched out and is now hosting multiple "forges". As part of this, we (the Eclipse Foundation staff) have started to distinguish between "The Eclipse Foundation" and "eclipse.org". The Eclipse Foundation is
the organization; eclipse.org is the forge.
As of today, there are three forges managed by the Eclipse Foundation:
eclipse.org
locationtech.org
polarsys.org
Each of these forges has its own website, Git repositories, Bugzilla instance, mailman, and forums.
These forges have considerable overlap. All forges use the same development process (EDP), and same IP Policy. The EPL is the main license for all forges. All forges share a single IPZilla instance. We also (internally) have a single system that we use for
managing all the various documents that committers are required to provide. A committer in one forge does not need new documentation to become a committer in a different Eclipse Foundation-managed forge.
The webmaster is currently working on consolidating the separate forges into a single LDAP instance. With this, we're changing the notion of having an "eclipse.org" account to that of having an "Eclipse Foundation" account. With that single Eclipse Foundation
account, you can authenticate on any of the forges. The rights that you have on the forges depends on your roles in that forge. You still need to be a committer on a project to make any changes to project metadata, for example. In practical terms, this change
should have no impact on any existing Eclipse committers.
Here's the important bit. The forges also share councils. There is one Eclipse Foundation Planning Council and one Eclipse Foundation Architecture Council. As time progresses, people from these other forges will be nominated to the councils based
on the exact same set of conditions that guide nominations from the eclipse.org community. These people will be natural choices to be mentors for new projects created in their respective forges. In the meantime, we need to lean on the existing members to help
bootstrap the new projects that are starting to trickle into the new forges.
For all practical purposes, mentoring a polarsys.org or locationtech.org project is no different than mentoring an eclipse.org project.
I am working on a web page that describes this with detail and fancy pictures.
As always, please let me know if you have any questions.
HTH,
Wayne