Lenny general freeze ahead
Marco Amadori wrote:
> A part the IRC list were longer and I asked you what you needed and
> implemented mosts of your taste requirements, I think I actually FIXED[0]
> coding style:
no. live-snapshot is part of userland, not initramfs. therefore
live-helper code style applies. that's what i said already.
>> err? you were basically absent in the last 15 month.
>
> Yes, I know, and all knows that I was "absent" because of work and new family,
> I do not have the spare time I was used to have, but I think I always declared
> that loudly, so it should be not a surprise.
you never needed and still don't need to justify for being busy with
other stuff, this is a volunteer committment after all. what i'm saying
is that just because it was different in the past doesn't mean it is
still the same.
> You could notice I was also
> unhappy about you forking casper, mainly because I was collaborating
> succesfully with some ubuntu "upstream" guys which were little disappointed by
> the move, but the real motivation of my absence was just family (and work)
> related, not technical nor personal by my side.
the fork was needed - nobody was working on casper in debian anymore,
and ubuntu did not merge from debian. do we need to reiterate that now?
> Ok to use right a tool, but here it seems just that the effort gives back so
> little. Topic commits are fine, splitting some small cleanings in 4 commits
> instead of doing just one "cleaned a bit live-snapshot" seems overwork and
> overzealous, moreover because they were 4 commits artificially split, not
> different works in different times, it seems an abuse of a VCS to me here.
this /is/ the right tool used the right way. if you're saying that your
big commit is right, then you're absolutely wrong. that commit is not
understandable itself (amongst others, also for the reasons pointed out
several times already) by me.
it is needed that i understand the commit since there is no other active
DD maintainer arround for live-initramfs yet, means, in case you
disappear again, i'm supposed to fix any upcoming bugs with that part.
apart from that, the 4 commits you are refering to are from *me*, not
taken out of your big fat one, otherwise i would have used --author.
> It requires more time to chat than to code. If cleaning like you want requires
> you 5 min, and chatting to know exaclty how do you want things requires 2 hour
> (latest irc session had this ratio) please use that 5 min to merge and "clean
> the personal taste uglyness" yourself, we will learn by example in less time,
> I'll assure that!
given someone contributes more than once, it requires more time to fix
code again and again rather than making the contributor delivering merge
ready code in the first hand. apart from the fact that the job of
correcting such things is tedious, also the poisoning of git diffs sucks
too.
> It's a methodology objection mine, not a technical. And the fixes I did WERE
> non technical, if you like I can discuss why the change you required from an
> "if return" to "if else" statement, although you liked more, was "better" as
> it was. (since if was an error condition trapping which is better served in
> term of understanding at it was before
because it's shorter, faster and easier to read.
> [1] vi /usr/share/doc/linux-doc-2.6.25/Documentation/CodingStyle.gz +237
> should be mentioned too although is C related, Chapter 4: Naming.
that just shows that you don't listen. i already explained that at least
twice, that shell functions are different by the very nature of how
shell functions are beeing interpreted: To avoid naming scheme conflicts
with external commands and thus beeing able to use shorter names,
functions are beeing written with a capital letter in live-helper.
comparisons to C simply do not apply, be it kernel.org or not.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann at panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Reply to: