Wayne Beaton is employed by The Eclipse Foundation where he works as an evangelist, spreading the word and helping folks adopt Eclipse technologies. Wayne has extensive experience in object-oriented software development and is a strong proponent of refactoring, unit testing, and agile development methodologies. He is also the editor-in-chief of Eclipse Corner, PMC Lead for the Technology Project, Project Lead for the Examples Project, and an advisor for osbootcamp. In 1982, he received the prestigious Chief Scouts Award from then-Governor General Edward Schreyer. In 1984 his team was selected to represent beautiful British Columbia in the Kinsmen Voyageur Relay. In his spare time, he writes down meaningless accomplishments from his youth in a lame attempt to impress the reader. Wayne is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

Revise the Eclipse Development Process

07.28.2012
| 2128 views |
  • submit to reddit

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!

Published at DZone with permission of Wayne Beaton, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)