[parted-devel] Call for organization

[leslie.polzer at gmx.net]

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?

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

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

> - 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.

  All the best,

    Leslie

-- 
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83
http://nic-nac-project.de/~skypher/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20061208/d5859ff9/attachment.pgp