Still More Eclipse Development Process Discussion

On March 22, I will be presenting my revised edition of the Eclipse Development Process to the Eclipse Board of Directors for their approval. I’ve been discussing the upcoming changes in this blog, and in a handful of bug reports, so I’m pretty comfortable with the ideas. But like many things in life, the delivery date has snuck up on me and I find myself scrambling a little to get all the words down right.

As I said, the ideas are all out there and I’m in a process of wordsmithing it all at the moment. The original document was built in the days before XHTML and stylesheets were popular, so I’ve been trying to fix up as much of the markup as possible while I’m at it while trying not to disturb the content any more than necessary (so that the viewcvs diff remains at least a little useful). I’ve tried to add annotations in places where significant changes have occurred. You can turn annotations on by clicking the appropriate link on the right side of the page. It occurred to me to let the document use more of the screen. Right now, it’s crammed into a relatively narrow band down the middle of the window. But then I thought of Ward’s TenWordLine and decided to leave it alone.

There are three major changes in the document.

First, I’ve removed the notions of Container- and Operating-Projects. Now we just have projects. All projects can opt to either have code or not. Projects can have downloads, builds, websites, etc. or not. Projects can opt to do roll up builds of sub-projects. I have also added some words that attempt to actually define the term “project” and have taken steps to deformalize the use of the term “sub-project” (a “sub-project” is simply a way of talking about a project that has a parent). I’ve talked about this particular change at length already.

Second, the notion of Incubators is made formal. Incubators do not do releases. They do not graduate. They do not require continuation reviews (or reviews of any form). Incubators remain perpetually in the Incubation phase. I have also already blogged about this.

Third, I’ve made an existing project creation loophole formal. New projects can be created directly from a restructuring review (I’ve also consolidated Move and Restructuring Reviews) without going through the proposal and creation phases under certain conditions (the scope must be preserved). This one, which came up as a side effect of Bug 241041 and the recently-announced Mylyn Restructuring, is potentially one of the more controversial changes.

There’s other less significant changes, like the elimination of the notion of a review call in favour of a “review period”. There’s nothing to prevent a call from happening, but there is no mention of in the process. I’ve also acted on some excellent suggestions for some wording changes in the section on project leadership.

The original document uses capitalization similar to what you might find in a legal document. I am inclined to change it to instead follow more common language rules. This will mess up the diff, so I may just put that particular exercise off for a while; I don’t believe that changing the capitalization of the text will require further scrutiny from the Eclipse Board of Directors.

And yes, there’s hyperlinks to the old version. Good idea.

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

4 Responses to Still More Eclipse Development Process Discussion

  1. Chris Aniszczyk says:

    On top of this, I filed a bug to consider us shortening the committer election cycle.

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=305544

    If you feel this is a good idea, please voice your support on the bug.

  2. Jeff McAffer says:

    I like the overall approach but as I pointed out in https://bugs.eclipse.org/bugs/show_bug.cgi?id=301065 this new draft does not deal with the project aggregation issue. There must be an explicit mechanism by which projects can be aggregated for community and process purposes. I’m not talking about infrastructure here.

    Take reviews for an example. The new EDP says that “All Projects are required to participate in at least one Review per year”. That is great but I did not see any affordances for aggregating many projects into one review. This goes for IP logs, plans and other “project” requirements. Without the ability to aggregate we will be forced to either a) have many more reviews, plans, etc or b) ignore the EDP and have projects that are not explicitly reviewed. If some subproject is to show up in its parent project’s review/plan/ip log, how should that happen to ensure the same level of rigor is applied to all projects?

    If there is no accepted aggregation then the parent project review/plan/… info is immediately called into question. Take a look at the Eclipse top level project’s Galileo review. http://www.eclipse.org/project-slides/Galileo/Eclipse_Galileo_Review.pdf. Lots of great, good looking info and lots of per sub-project (Platform, JDT, PDE, …) info. What of PDE Build? Compare? Team? JDT Core? Under the new model they would be “projects” like any other and should have reviews/plans/logs/…

    The numbers on page 2 look reasonably healthy but where are the 7 breaking changes? Are they all in one sub-sub project? Are there sub-sub projects that have no active committers?

    My point is NOT to say that we should have that fine level of info (please no!) but rather to question whether or not we can really say that Compare, PDE Build, Team, … “participated in a review” in 2009. If we say that they did, then all of the words describing what a review is and what a project must do, did not apply to those projects since the defined information was not presented.

    So, the reality is that there are some sub-sub projects that do not have to have a full review as defined by the EDP because they are subsumed by a parent project.

    Perhaps the right answer is for the Eclipse team to eliminate all of these fine-grained commit rights but that is a pretty big thing that should be raised explicitly. If that is not intended and nothing changes, then this new EDP will not match reality and we’ll be no better off.

    Personally I think we should have an aggregation mechanism. Without it communities legitimately needing/wanting to create subprojects for infrastructure reasons (e.g., commit rights) will have to walk this ill-defined process line and will not know how many reviews, ip logs, plans, … they need.

  3. Mike says:

    Wayne: do Incubators have to host their code on the Eclipse Foundation’s server? Could an Incubator be hosted on Github, Rubyforge, Google code or (gasp!) CodePlex?

  4. Wayne Beaton says:

    @Mike. Yes and Yes. I intend to blog more about this later.

    @Jeff. The current (2008) version of the EDP contains the words “All Projects are required to participate in at least one Review per year”. The status of PDE Build, Compare, JDT, Core, etc. really doesn’t change with this new edition. In the EDP that predates 2008, these were known as components. The 2008 edition added words along the lines of Component == Project (i.e. it’s just a name).

    Anyway… we’ve been doing aggregate reviews, aggregate project plans, and aggregate IP Logs for years. Nothing in the new version changes this. I will, however, attempt to add some words to formalize this. More later.

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