vert-x3 / eclipse-proposal-wip Goto Github PK

However, Bower requires a Git repository on which tags are “manually” created after the
release. The tag contains an updated version of the vert.x event bus client (Socks) and
updated metadata. It is not known yet if such a process is compatible with Eclipse guidelines.

The implication is that changes are introduced with these tags. If these changes are bug fixes or otherwise minor changes that do not introduce new functionality, then we would regard them as "service releases" which to not require any sort of formal review or ceremony.

If the changes introduce significant new functionality or change APIs, then a more formal release review will be required.

Each existing Vert.x module stays in its own repository and is moved to a Github
organization owned by Eclipse.

We currently only support a single GitHub organization for all Eclipse projects. We expect to move the additional Vert.x repositories into the existing Eclipse organization.

I'll admit that we've been wrestling with whether or not it makes sense to create a separate organization.

The Eclipse organization is, frankly, a mess and it's difficult to find anything from the organization's landing page. Is it significantly better for the existing Vert.x GitHub organization? i.e. do people actually use the organization landing page to find a repository for a particular functional area?

IMHO, the project website is the right place to point people to the right repository by, for example, providing logical groupings of repositories.

This repository shall be co-managed by Eclipse
and a defined number of the Vert.x/Eclipse team.

Since committer access to project resources needs to be carefully managed (e.g. we need to ensure that committers have the necessary paperwork in place), Eclipse Foundation staff will take exclusive responsibility for providing management within the organization.

The project's website should be moved to http://www.eclipse.org/vertx

All existing web properties (e.g. vertx.io) should redirect here.

Note that the custom website is still possible. In the absence of a website implementation, the current URL redirects to the automatically-generated "PMI" website.

The document suggests that each functional area has its own repository with its own development team. Numerous Eclipse projects have multiple repositories spanning multiple functional areas and who gets to write to a particular repository is controlled via social conventions rather than via strict access controls. In short, we trust committers to do the right thing and follow the rules laid down by the project team.

So my question is about motivation. Why do you need to carefully manage who has access to what repository?