Comments (9)
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.
from eclipse-proposal-wip.
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 [email protected]:
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
#4 (comment)
.
from eclipse-proposal-wip.
+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
from eclipse-proposal-wip.
In what ways are the subprojects independent? i.e. do they release on different schedules, do they have different communication channels?
from eclipse-proposal-wip.
Yes, the projects are independents.
- Some are release together (in a single release process).
- Some are release asynchronously (parent poms, vertx-mysql-posgresql-client, ...)
- Some are not released, because are not considered as "production-ready" or stable enough to be released as "technical preview"
from eclipse-proposal-wip.
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.
from eclipse-proposal-wip.
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).
from eclipse-proposal-wip.
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.
from eclipse-proposal-wip.
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 ?
from eclipse-proposal-wip.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eclipse-proposal-wip.