[parted-devel] Call for organization

[rohit hooda]

--- David Cantrell <dcantrell at redhat.com> wrote:

> 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.
I would like to work on this ... i.e. for getting the
ext3 support in. I have had a few mail exchanges
earlier with leslie regarding this ( a long time ago )
but nothing worked out :(. I guess I can may a fresh
start now and get things moving on this front.

Let me know your comments.

-Rohit


> 
> >> 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 
=== message truncated ===



		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/