[parted-devel] [PATCH] mkpartfs ext2 2 10 would erroneously report "file system too small"

Fri May 18 20:27:52 UTC 2007

David Cantrell <dcantrell at redhat.com> writes:

> On Fri, 2007-05-18 at 15:18 -0300, Otavio Salvador wrote:
>> David Cantrell <dcantrell at redhat.com> writes:
>> > We also need to take in to account that the parted code base is not in
>> > great shape.  It's had many hands in it and we all are trying to bring
>> > it up to date and correct a lot of defects.  Jim's patch clears a make
>> > distcheck failure which, in my opinion, is more important in the short
>> > term than a unit test for the function.
>> 
>> I agree completely with you while I think we should at least wait for
>> a consensus _before_ commit.
>
> Sure.  In this case, I think Jim was assuming this was a relatively
> trivial fix and everyone was on the same page for it.

Yes, I think he did and there's no problem with it. I think we all
already did it (I did, at least) ;-)

>> > As development progresses and we begin making more substantial changes
>> > to parted, we can start enforcing more strict policies such as requiring
>> > full unit testing for a new function at commit time.  For now, I think
>> > we should all be a little more flexible with regards to incoming
>> > patches.  If it fixes a bug, let's take it.
>> 
>> I don't agree completely. While I accept that it can slowdown the
>> development speed I also think that if we don't _try_ to produce
>> patches for every change we do we won't get a good unit testing.
>> 
>> Writting tests take time and I'm sure we all are busy people who lack
>> the need time to work at Parted and other projects, if we don't try to
>> keep them up they'll just die and then no useful tests will be written
>> since development has to be done.
>
> I don't think anyone is disagreeing with this plan.  My point is that
> right now the changes we are making to parted are either really tiny and
> virtually unnoticable -or- they are huge rewrites of a lot of bad code.
> If a developer can contribute a good patch, but does not provide a test
> case, we're not throwing out that patch if it works.  Someone here can
> write the test case.

Sure not. For example, your 512 sector patch is very difficult to
write tests for and would be the case.

> I may be missing something, but was there a problem with you writing the
> test case if Jim had submitted the patch (forget for the moment that the
> commit came before patch review on the mailing list....assume that
> happened)?

Sure not. If you read my first message I asked if he could do it. In
my understanding, _could_ if different of _must_. See:

Can you try? See? Is different of: Hey, write a test otherwise forget
about your patch! :-D

>> I'd still want to write an indent script to format the whole tree code
>> and check against mistakes but I also think we _need_ to define the
>> code style before I can do it.
>
> Right, the script comes after the definition.
>
>> I personally dislike the 8 spaces and I'm starting to think that tabs
>> might grant the visual flexibility we might need. Most of time 2 or 4
>> spaces are enough and makes easier to avoid line breaks.
>
> Tabs now?  I thought we were all in the spaces camp.

I read the Hakon mail about it and it made me rethink it. Maybe he's
write about it. Looks like tabs are much more flexible for us allowing
us to see the code how we wish to.

> I'll say my personal preference is 4 spaces for indentation, never tabs
> in C.  I use tabs in Python code.

I agree that 4 looks good in most of cases. Maybe we might start a
thread for coding style? :-)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio at debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."