Re: [eclipse.org-architecture-council] Multiple forges at the Eclipse Fo

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Yes it does – thanks.

 

I’m having a trouble understanding how polarsys could release into the Eclipse.org release train, when they are allowed to host LGPL projects – but I agree that’s a question to ask once they express interest in joining the train, so let’s defer for now.

 

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 Mike Milinkovich
Sent: Monday, April 22, 2013 1:09 PM
To: eclipse.org-architecture-council@xxxxxxxxxxx; eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Multiple forges at the Eclipse Foundation

 

 

Martin, 

 

Good question! 

 

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. 

 

Does that make sense? 

Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223

From: Oberhuber, Martin

Sent: Monday, April 22, 2013 3:52 AM

To: eclipse.org-architecture-council

Reply To: eclipse.org-architecture-council

Subject: Re: [eclipse.org-architecture-council] Multiple forges at the

Eclipse Foundation

 

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

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects