[parted-devel] Call for organization

[David Cantrell]

Leslie, Otavio, Anant, Debarshi, and other contributors to GNU parted/fdisk,

I'd like to take some time to work up a project structure, get an idea
of what goals we're working towards, and have people take
responsibilities for various parts of the project.  I have no intention
to halt things or throw wrenches in to the gears, but I think we need a
little more defined structure so that we all know what we're working
towards rather than just hacking in general.  I've written up the
following as a summary of what our plan should be.  It's probably like
stating the obvious, but sometimes that needs to be done so that
everyone is on the same page.

DESCRIPTION
The GNU Parted project is an open source disk partitioning utility
primarily geared towards Linux, but designed to work well with other
open source operating systems.  The primary focus of development is
libparted, a C library providing all of the partitioning and filesystem
functions.  A frontend for this library is provided as the parted(8)
command line tool.

GOAL
Supplant fdisk(8) as the primary disk provisioning tool on all Linux
platforms by providing seamless partitioning and filesystem creation
support in one software package.

PLANS
The immediate plans for GNU parted are moving towards a 2.0 release and
continuing maintenance of the 1.x release line.  The 2.0 release will
incorporate a number of changes, all centered around a library overhaul. 
  Though there are bound to be a number of intermediate releases so that
users can test features, the ultimate 2.0 release will contain the
following features:

1) libparted API overhaul.  Inconsistent function naming has caused
confusion for some developers.  Functions will be renamed to follow a
defined naming pattern (for example, see libglib).  Functions we come 
across that are no longer necessary, toss.

2) Python bindings for libparted.  An external project currently, the
pyparted project provides a 1-to-1 mapping to libparted interfaces from 
C to Python.  This allows Python developers access to libparted 
functions, but not in the most elegant manner.  A rewrite of pyparted to 
offer an object oriented API as well as the traditional 1-to-1 interface 
is planned, with eventual inclusion in to the GNU parted project code base.

3) Full API documentation.  Probably using doxygen since it can generate
nicely formatted API docs.  Some functions have nothing written for 
them, other functions do.  This needs to be finished up and docs need to 
be provided for libparted.

4) Unit testing framework.

5) Filesystem VFS layer.  Current filesystem support was written from
scratch and presents numerous problems for extending support to new
filesystems or additional filesystem features.  Case in point, ext3
extended attribute support.  A reworking of the filesystem support
system in libparted is essential to ensure we can integrate future
filesystems and filesystem features.  At the same time, removing the
homegrown filesystem code and using the filesystem libraries that are
already out there will remove some unnecessary work in libparted.

The 1.x branch will continue to receive bug fix updates as necessary and 
releases along the 1.8.x line will be made.  No new major features are 
planned for the 1.x branch.

TEAM
We have a great group of volunteers at the moment, but we seem to lack 
any formal structure.  I want to have some sort of organization in place 
so we all know who has responsibility for certain areas, who to go to 
for a particular question, and so on.  With that in mind, here are the 
positions I think we should have:

1) Project Leader.  Pretty much self explanatory.  Responsible for 
overall project.  This person should be an experienced C coder as 
contribution to parted is expected as well as patch review.  This person 
should also have an interest in leading the project and handling those 
aspects.

2) Infrastructure Lead.  Responsible for all of the IT-type things for 
the project.  The revision control system, the mailing list, the web 
site, and other things.  This person should be an experienced sysadmin 
and knowledgeable with version control systems.

3) Maintainer.  A maintainer would be in charge of a specific branch. 
We have 1.8.x set up as our stable branch and then we have the edge 
branch which, I assume, we'll make releases off of for testing.  The 
maintainer is also a contributor, but is the final person who wraps 
everything up for release and makes the release.

4) Contributor.  Everyone else who regularly contributes to the project, 
but is not one of the above positions is considered a contributor. 
Contributors can have specific focus areas or not.

WHAT NEXT?
I want to get names attached to the above positions and then move 
forward with the plan for parted 2.0.  That should include:
- Everyone commenting on the plan, adding/removing ideas
- Assigning areas to specific contributors
- Getting a rough schedule in place for some 1.9.x test releases

-- 
David Cantrell
Red Hat / Westford, MA