[
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
