Containers, Operating Projects, Oh my!

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.
  • There is no roll up of committers; the set of committers on a project is exactly that set of people who have been explicitly elected into that role for the project (i.e. being a committer on a “child” project does not give you any automatic rights on the “parent” project).
  • A project may choose to do roll up builds and provide roll up downloads of its subprojects
  • The entire leadership chain of a project must be consulted for approval of those things that require approval. A project must, for example, obtain approval from the PMC of its top-level project and the project leadership of any parent project to do a release.
  • Nesting of projects is limited to a depth of “three”. i.e. top-level.parent.child
  • 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?

    This entry was posted in Community, EDP and tagged . Bookmark the permalink.

    5 Responses to Containers, Operating Projects, Oh my!

    1. A picture (or two) would really help clarify the proposed structure.

      Sounds good, but seems a bit confusing on first read.

    2. Wayne Beaton says:

      Less confusing was what I was going for. Perhaps it needs more work.

    3. I agree that this is a good start on the road to clarity. Just think that if you can come up with a view pictures, it would help to explain your vision. A couple of different views might be useful:
      – Project model (show projects/sub-projects and committer communities)
      – Version control model (shows how code is stored)
      – Approval model

    4. Boris Bokowski says:

      Makes sense to me, and I don’t think the two controversial issues are really that controversial. I couldn’t agree more that fine-grained control doesn’t work well.

      One thing we should strive for is having a good “target number” of how many committers make sense for each project, and making it easy to refactor projects (merging and splitting). I can see both very small (one- or two-person) projects as well as huge projects (where to draw the line? 20+ active committers?) as problematic. For too small projects, there is not enough socializing, communication, and cross-pollination. Projects that are too large suffer from a lack of cohesion, lack of caring, and it’s difficult to build a sense of team and trust.

    5. One project … as many repositories as a project wants (at least that’s how it looks like with Git) … one group of committers. After all, it’s an SCM and mistakes can be reverted.

      Do we really need sub projects, sub-sub projects, sub-sub-sub projects? IMHO nesting only makes sense if there is some inheritance from parents to children. But there isn’t! Committers, mailing lists, newsgroups, permissions, bugs … nothing is inherited. The only thing that happens is a “grouping” of projects under a PMC to allow some sort of management and control and simplification (eg.m joint release reviews). I think that’s fine.

      Now the PMC has a project for itself with the PMC members as committers, web space and repositories. Seems fine to me. Or am I missing something?

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )


    Connecting to %s