I’ve been wrestling with this one for a while… Just what is the role of a container project? I asked this question more formally in Bug 301065. I invite you to make your comments. The Eclipse Development Process is, after-all, your process.
Frankly, I think it’s time to do away with the notion of container projects. I think that we can move forward with a single notion of a project. Here’s what I’m thinking.
- A project has exactly one group of committers that have write access to the various resources owned by that project. From the Webmaster’s point-of-view, this means that each project has exactly one UNIX group.
- Projects manage access to their various parts using social convention (this is already happening today on most Eclipse projects)
- A project has zero or one of each of the following resources: a source code repository, a website, some space on the downloads server, some space on the archive server, access to a build server, etc.
- A project must have at least one project leader.
- A project may have one or more subprojects. Subprojects have their own distinct group of committers, and resources. We may refer to the organization of projects using whatever language makes sense to the target audience and broader community (e.g. “parent project”, “child project”, “subproject”, …).
- A project’s source repository should be separate and distinct from the source repository of its “parent” project.
I think that the most controversial thing here is the notion that a project can have its own code repository and subprojects. For what it’s worth, this is already happening in some Eclipse projects. I’ve always found the limitation against this very artificial. The one part of this that bothers me is overlapping repositories. I don’t think that subprojects should exist within the source code repository of the parent project: this just leads to confusion with our Dash tooling and adopters (who have to sort out which parts of the repository belong to which project). Confusion leads to anger. Anger leads to pain. Pain leads to suffering. Of course, some projects are doing this today, so maybe I’m overstating the problem (we should be able to sort out any possible issues with Dash).
Probably the second most controversial thing suggested here is the notion of a single group of committers for all of a project’s assets. Experience has shown us that managing fine-grain control to the various resources just doesn’t work well. Nobody seems to understand who should (and does) have access to what. For me, the responsibility that comes with being a committer includes the responsibility to know where you’re supposed to be working. On the Examples project, for example, committers working on the Toast example, just don’t commit on the Slideshow example. They just don’t. This, despite the fact that they have full access. Frankly, if you’re not sure that you can trust a developer to follow social conventions, then maybe you need to rethink nominating them as a committer.
At least that’s what I think. What do you think?
