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.
