[parted-devel] Parted Stuff that needs fixing before 1.8.9

Joel Granados jgranado at redhat.com
Thu May 21 09:13:34 UTC 2009


Hello Matt.

Yep, this is something that could be evaluated.  Questions bellow.
On Wed, May 20, 2009 at 08:12:52PM -0400, Matt Davis wrote:
> On Wed, May 20, 2009 at 11:28:15AM +0200, Joel Granados wrote:
> > Stuff that I think should go in the next branch
> > 1. [PATCH] Initial btrfs support, only recognize it for now
> >     - http://lists.alioth.debian.org/pipermail/parted-devel/2009-March/002741.html
> > 
> > 2. [parted-devel] please support m68k atari partitioning
> >     - http://lists.alioth.debian.org/pipermail/parted-devel/2009-March/002743.html
> > 
> > 3. [parted-devel] [ PATCH ] extended attributes support on ext2 and ext3 filesystem
> >     - http://lists.alioth.debian.org/pipermail/parted-devel/2009-April/002777.html
> >     * This is something to look at.  More specifically: 
> >       a. Does the patch included in that mail increase the ext{2,3}
> >          detection capabilities in parted?
> >       b. Does that patch include more code than we are comfortable with
> >          (having in mind that we want to move away from fs handling)?
> >       c. Would separating the useful stuff (detection only) from the
> >          other stuff be worth it?
> 
> What about the "history/save" feature?  More or less, I threw together a few

So this is something you would activate?  Like calling parted with a
special argument so this get activated?


> patchset a while back, that did not perform any disk changes until a "save"
> command was issued.  All of the commands to execute were queued, so that the

Why use a queue?  Why not use the parted internal structures (and not do
a commit like we currently do) but just change the internal structure.
After the user has given the save call disk.commit()

> user could undo/redo changes before committing to disk.
> 
> http://lists.alioth.debian.org/pipermail/parted-devel/2007-November/002034.html

This is a _very_ old patch 2007 :).  Any plans to rebase it to current
git (next branch would be best)?

> 
> I did not get much feedback, but it might be due some thought for a future
> branch.
> 
> Cheers
> 
> -Matt

Regards.

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.



More information about the parted-devel mailing list