Revise the Eclipse Development Process

I’ve proposed a session titled “Revise the Eclipse Development Process” for EclipseCon Europe 2012:

It’s time to revise the Eclipse Development Process (EDP). In this interactive session, we’ll discuss how we can revise and modernize the EDP. This is intended to be the continuation of an ongoing discussion that will result in updates to the Eclipse Development Process (targeting early 2013).

For example:

  • It takes a minimum of three–more likely, four–to start a new Eclipse project. Can we change the EDP to make it so that a new project can get started in a week?
  • How valuable are reviews (release, graduation, restructuring, termination)? Does the EMO need to be involved in all reviews, or is this something that projects should decide for themselves how they can best inform their respective communities of important project milestones (perhaps in conjunction with their PMCs)?
  • Must all committer elections be run over five business days, or should projects be allowed to decide for themselves how to run their own elections? Do we need a software system (e.g. the Developer Portal or the new Project Management Infrastructure) to manage elections, or should we go back to the “good old days” of running elections in the project’s developer list according to guidelines established by the project and their corresponding PMC?
  • Who uses IP logs? Now that most projects are using Git, we have excellent tracking of IP contributions and can automatically generate a log without committer intervention (i.e. we no longer have to explicitly mark Bugzilla patches). Logs can be easily generated on demand; do we really need to submit and have them approved?
  • Can we kill off piggyback CQs?

Note that not everything in this list is included in the EDP, but we will discuss them anyway as a means of driving change where change is required. Be prepared to contribute to the discussion. No topic is off limits, but we will limit the time allotted to individual topics to ensure that we’re able to cover everything.

Over the past couple of years, I’ve established a pattern of regular updates to the EDP. I’d like to consider some more radical changes this time around. As I stated in the session abstract, I’d like to make this happen in early 2013. This means that the conversation has to start now. My plan is to use Bugzilla to discuss possible changes with the Architecture Council (Community/Architecture Council), discuss it in person at EclipseCon Europe 2012, and then run a survey of all committers to ensure that we’re hearing from everybody. Feel free to open up your own bugs.

Oh… and submit your own talk, and keep your eyes on the registration dates for EclipseCon Europe 2012. I am looking forward to seeing you there!

EclipseCon Europe 2011

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

One Response to Revise the Eclipse Development Process

  1. da152 says:

    Sounds like a good talk for ECE🙂 Maybe you should have a BoF after the talk for a more detailed discussion.

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