On Tue, Sep 22, 2009 at 11:33:51AM -0500, David Lehman wrote: > On Wed, 2009-09-16 at 14:43 +0200, Joel Granados Moreno wrote: > > * storage/partitioning.py (doPartitioning): By default we run both the > > grow code and the allocation code. We could, If we were very careful, > > avoid running either the allocation or the grow parts. > > This still makes me very uncomfortable. It seems like a pretty big > change to the process for a limited value-add. Is the purpose of this so > that you can toggle growth on demand or is it so you can identify free > space between initial allocation and growth? Its to find out if there is free space so the user can add a new partition. As I said on my original post, I'm not proud of the way I did it :). > > I have a patch waiting to go into post-F12 rawhide that completely > reimplements growPartitions. If the endgame of this patch is to find out > if there is free space before partitions are grown, there are much less > disruptive ways to do that. Here's a link to the current patch, just in > case you want to take a look: > > http://dlehman.fedorapeople.org/20090915-grow-partitions.patch > hrm. considering your patch and the fact that the UI rewrite stuff can live without this part [1], we could put the free space calculation logic after the UI stuff goes in and your partitioning.py stuff goes in. In that way we don't step on each others feet :). I'll take those two patches out of the patch set. I'll also create one patch that comments the logic behind the use of the free space function. So when the free space function is created, we just need to uncomment the code. [1] : In my original post I described how we can avoid putting this patch in. -- Joel Andres Granados Brno, Czech Republic, Red Hat.
Attachment:
pgpl3VIRef5dm.pgp
Description: PGP signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
