[parted-devel] Call for organization

[David Cantrell]

leslie.polzer at gmx.net wrote:
> Hello David,
> 
>   thanks for your informative mail.
> Here's my statement:
> 
> On Fri, Dec 08, 2006 at 11:24:32AM -0500, David Cantrell wrote:
> 
>> DESCRIPTION
>> The GNU Parted project is an open source disk partitioning
>> utility primarily geared towards Linux,
> Is it?  How can you support this statement?

Because I haven't seen it used in any other open source operating 
systems as much as I have in Linux.  Someone correct me here if I'm 
wrong.  The code base currently is mostly useless to non-Linux operating 
systems as a primary partitioning tool.

>> 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.
> Yeah.  That's the place where the Wiki comes in.

My original understanding of the wiki suggestion was more of a 
discussion forum, and that didn't make sense to me.  For specifications 
and docs and other such reference material, I think a wiki is a good idea.

>> 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.
> I wonder if we really need this, and whether a shell-based interface
> wouldn't be easier _and_ appeal to a larger audience.

pyparted is in use by every distribution that uses anaconda (that 
includes Fedora, RHEL, CentOS, Yellowdog, rPath, and the list goes on). 
  Gentoo as uses pyparted for the installer project(s).

I'm more interested in multiple language bindings to make libparted as 
usable by other projects as possible.  Otavio mentioned this.  C++, 
Perl, and so on (PHP?  hahaha, that would be amusing!).  Shell bindings, 
sure.  My suggestion of pyparted is (1) it's already there and (2) it's 
in use in a lot of projects already.

>> 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.
> Most stuff is either self-explanatory or has docs.  A tutorial
> introduction and frameworking explanantions are needed, not much more.

Fair enough.

>> 4) Unit testing framework.
> Otavio's working right on this, but I don't know who will code all the
> tests.  It seems a lot of work.  I originally planned to pay someone to
> do it via bounties, but as long as we haven't received the donation I
> have applied for, this obviously won't work out.

This will be a lot of work.  I don't think it's necessary to pay 
someone.  I think once the bulk of the test suite is written, 
maintaining it will be less difficult.  It's the initial 
getting-over-the-hurdle stage that's hard.

>> 5) 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.
> That's a blanket statement.  For example, Parted has most likely the
> best FAT implementation there is.

So #5 was written while I was thinking only about Linux filesystems. 
The ext2 support leaves a bit to be desired.  FAT, yes, I don't think 
there's a better alternative anyway.

Regarding the VFS layer...if we write it to where new filesystems can be 
easily added, we can then pick and choose which ones we want to use 
external libraries for and which ones we just keep our code for.

>> 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.
> We already have people filling those positions, and it's working fine
> (at least that's my impression).  I would really appreciate it if Anant
> took up the lead in position 2), since that would free me from all the
> stuff that keeps me from producing code and reviewing patches as
> throughly as I should.
> 
>   I have a personal interest in continuing to be the representative person
> for Parted, but, basically, I'd be content with the developer position
> if someone objects to it.

All sounds good to me.

>> 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.
> I think most people call this "developer" and leave "contributor" for
> people who have sent one or more patches but do not have RCS write
> access.

Good point.

>> - Everyone commenting on the plan, adding/removing ideas
> I'd really like to see the Wiki set up before we get to the details.

OK, let's move forward with the wiki idea.

>> - Assigning areas to specific contributors
> Fine!  I'll get to this in another post.
> 
>> - Getting a rough schedule in place for some 1.9.x test releases
> Speaking of which, I would like to hand over the lead for 1.x entirely
> to you.  This sort of already happend, but I'd like to assert this.
> You have done a very good job on this.

Thanks.  Yeah, it has sort of happened already.  So I guess that means 
I'm the 1.x Maintainer (unless we're picking different terminology).

-- 
David Cantrell
Red Hat / Westford, MA