Containers, Operating Projects. With Pictures

In my previous post discussing pending change in the Eclipse Development Process (EDP), I tried to present my view of what projects should look like at Eclipse. Scott suggested that a few pictures might help. It’s important to me that these concepts be understood. Therefore, I present: The. Best. Graphics. Ever.

First, there’s the relatively simple version.

A project has a parent. In this case, the parent is a top-level project. The project also has resources. I’ve shown a web site, VCS, access to the build server, and space on the downloads server in this image. I’ve also shown a group of committers. This group of committers has write access to all project resources. If you have write access to one of these resources, you have write access to them all. A committer is a committer is a committer. Projects that need finer grained access control to their resources will have to manage that access via social convention. Social convention seems to be working very well in several projects already, including CDT, Equinox, RAP, and more.

Over the past few years, we’ve tried (for reasons I don’t quite understand) to avoid using the word subproject. This next image, however, shows just that.

Here, we see that a project, in addition to the various resources and committers is has, can also have zero or more subprojects. Each of these subprojects has its own distinct set of resources. Each subproject also has its own distinct group of committers. Sorry to get technical with the language, but the group itself is distinct. Two distinct groups can actually share committers. As I mentioned in my previous post, each group of committers translates into a single UNIX group that has uniform access to the project’s resources.

A project has only the resources it chooses to have. That mid-level project could, for example, decide that it doesn’t need a VCS to maintain source code. That hypothetical project would, in effect, be just like what we call a “Container Project” in the EDP today.

This opens a question: what is the point of those container projects anyway? Well, I think they provide all sorts of different kinds of value. By making them a little more flexible, we leave it to the projects themselves to decide if and how they want to leverage the structure. Projects can still choose to do (or not do) roll up builds, roll up IP Logs, roll up downloads, roll up reviews, etc.

Ultimately, it should result in less work for projects that want to introduce subprojects (for whatever reason). With the current EDP, an operating project must become a container project in order to have even a single subproject. This means that the existing project has to move it’s code into another separate subproject. You can still do that with the change proposed here. You just don’t have to.

I think it’s the ability to choose what’s right for your project that’s key.

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

One Response to Containers, Operating Projects. With Pictures

  1. Rocky says:

    This is a wonderful change! Being able to structure projects as described adds for a lot of flexibility that is needed on more complex projects.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s