Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-committers] Standardized Groups and Why You Care

Eclipse Committers,

We want to help you get stuff done. Sometimes we don't get to help you out as fast as we'd like because we're bogged down managing the many inconsistencies in our environment by hand. We want to change that--feedback tells us you want us to change that--and we think bug 198541's implementation will get us there. So here's a run-down of what we're going to be implementing over the next year, how it impacts you, and why it's good for all of us.

*** Projects, sub-projects, and components will not only all get equal treatment in the revised Development Process, but they will also get equal treatment in our tooling. That effectively extends our tooling and support structure to handle many layers of projects. That means first-class treatment for components, including portal-based elections.

*** Each leaf project (whether top-level, sub-project, or component) will correspond to one Unix group.

*** Project management will have full tooling at their disposal to manage the creation and removal of sub-projects, and components and hence Unix groups in a way that is consistent with the Development Process. You won't have to worry about whether you are doing the right thing because the tools will step you through the process. To make managing this more convenient, simultaneous elections to multiple project leaves will be handled with a single nomination and unified/single voting.

This puts a lot of control into the hands of the projects, simplifies everyone's life and standardizes group naming to match project leaves. What you get is easier management and faster response times, what we get is the ability to better automate jobs and provide you with improved tooling.

This is how we'll be implementing this over the next year:

*----- 2008 -----*
*Q1:*
Focus on getting the internal software infrastructure prepared for the migration. This is in progress.

*Q2:*
Re-audit our internal database and paperwork in preparation for migration. Move tooling and scripting into the Portal and get the existing Portal code ready to handle the new scheme. We will need help from the projects to manage the audit. One lucky project will be migrated to build experience for tooling to be built in Q3... any volunteers?

*Q3:*
Allow project from Q2 to use the new sub-project mechanism via the Portal including elections and project meta-data.

*Q4:*
Further enhancements to the software processes and migration of a willing top-level project and all of its sub-projects.

*----- 2009 -----*
*Q1:*
Minor enhancements in functionality, large migrations--about half the projects will migrate.

*Q2:*
     Mass migration.  The other half.

This could change as we progress and we'll do our best to keep you, the community, up to speed with progress. Input is, of course, welcome on bug 198541.

Cheers,
the Foundation Staff


Back to the top