Eclipse projects have a single development team with homogeneous access to project resources

[waynebeaton]

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?

[cescoffier]

I can definitely understand the question, as I did have the same at the beginning. It's actually a matter of responsibility and expertise. Each component has an official maintainer that has commit right (or push right) on the component repository. However, when he wants to modify another component/repository, he must open a PR to get a review. The change would be merged by someone having the knowledge of the component. Actually, even on its own repository, he should open a PR, but at least he can merge it.

This is because the vert.x ecosystem is really broad. The maintainer of the AMQP bridge, who has a deep knowledge about the AMQP protocol, may not have the required expertise to modify the code generator (codegen), or the JDBC async client.

Could we achieve this we just good practices ? Yes. But here we have some control.

[tsegismont]

I agree with Clément. As a matter of fact, we have a similar process on the other project I'm involved in, and I would say this way of managing permissions is pretty common on open source projects shared on GitHub.

2016-01-20 7:37 GMT+01:00 Clement Escoffier notifications@github.com:

I can definitely understand the question, as I did have the same at the beginning. It's actually a matter of responsibility and expertise. Each component has an official maintainer that has commit right (or push right) on the component repository. However, when he wants to modify another component/repository, he must open a PR to get a review. The change would be merged by someone having the knowledge of the component. Actually, even on its own repository, he should open a PR, but at least he can merge it.

This is because the vert.x ecosystem is really broad. The maintainer of the AMQP bridge, who has a deep knowledge about the AMQP protocol, may not have the required expertise to modify the code generator (codegen), or the JDBC async client.

Could we achieve this we just good practices ? Yes. But here we have some control.

— Reply to this email directly or view it on GitHub https://github.com/vert-x3/eclipse-proposal-wip/issues/4#issuecomment-173109489 .

[purplefox]

+1 Clement.

One way to think of this is: Vert.x is not a single monolithic project, it's a set of sub projects under an overall "Vert.x" parent project.

The component maintainer is effectively the project lead of the sub project.

The model we use is described in more detail here:

https://github.com/vert-x3/wiki/wiki/Vert.x-3-Official-stack-and-component-maintainers

[waynebeaton]

In what ways are the subprojects independent? i.e. do they release on different schedules, do they have different communication channels?

[cescoffier]

Yes, the projects are independents.

1. Some are release together (in a single release process).
2. Some are release asynchronously (parent poms, vertx-mysql-posgresql-client, ...)
3. Some are not released, because are not considered as "production-ready" or stable enough to be released as "technical preview"

[waynebeaton]

Okay. That makes sense to me.

We can make this work. We'll use the notion of subprojects as defined by the Eclipse Development Process. Each subproject will need to have a designated project lead and we can use standard committer elections to turn contributors into committers.

[vietj]

We don't see the need to make Eclipse subprojects for the moment. This is not a need of the Vert.x project and having this big organizational change will introduce lot of complexity and latency. This is just something to solve a problem that does not exists today.

When you say we'll use you are just speaking as if you would decide for us. Keep in mind we are trying to reach an agreement that works well for everyone.

What we want is simply this:

• A dedicated GitHub organization
• organization is managed exclusively by Eclipse
• a special team of the GitHub organization with the project lead has powers on the GitHub projects and can assign members

This ensures that

• only PMC (or whoever else manages that in Eclipse) manages the members of the organization
• the project leads ensure that the developement Eclipse Vert.x follows the process by managing the access (and that is actually a concern that belongs to the project lead / project scope).

[waynebeaton]

Each repository must be owned by a project team. If the project teams are to be different for different repositories, then the only mapping we have with the Eclipse Development Process is to have each development team be separate (sub)project.

[vietj]

There are big problems with this:

• it is not dynamic (so not agile)
• it means that the code organization is 1-1 coupled with the project organization

In other words i.e if we want a new repository of code, then we need to create a new sub project with a lead, etc.... And if we want to retire one then we need then to remove it.

For what sake should it be so ?

So, at the end of the day if we follow this (and I'm saying if), we will have a single repository with all projects in it, you know, the 2000 style.

Is this really this kind the kind of project management Eclipse wants to propose ?