[EMAIL PROTECTED] 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
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
