Lenny general freeze ahead
On Tuesday 03 June 2008 23:01:59 Daniel Baumann wrote:
> - don't change unrelated things
> - don't change coding style
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
$ grep -e '[::alpha::]* ()' scripts/live
$ grep -e '[::alpha::]* ()' bin/live-snapshot.old
$ grep -e '[::alpha::]* ()' bin/live-snapshot.new
So , IMHO things are not consistent as it was, I just, while adding a feature,
fixed that (uglyness) non uniformity. 
Anyway, think again please and ask again if is it the case to not fix the
coding style... anyway I do not want to fork the code just to let it adhere to
my coding style... it could be just difficult to collaborate then, but such
things does not happen in the real world. ;-)
> > since I'm used to XP which leaves
> > you the good (IMHO) and bad (ITIYHO) habit to always refactor and
> > reformat the code one is working whit.
> as said on irc already, there is no point in merging stuff that makes
> existing code uglier wrt/ coding style when it can be that easy to
> correct it.
A part from , I'll see if is needed.. and if you do not want to change your
mind this time too, I hope to find some time to do what you will ask, even if
I find it useless and not well motivated.
> >> if it's possible to merge them from a git branch.
> > This was done too.  I could rebase it if needed.
> please do so, and please correct the other things i pointed out on irc
> to be changed. if you don't remember them or don't have a log, i can
> send one.
Done just the rebase for now.
> > A good thing to rush to, should be the debian-installer integration and
> > testing (maybe I'll do in the work hours like latest 2 features If I
> > could convince again my boss we need this feature and push the priority
> > up) .
> d-i integration isn't the problem from live-helper point of view, the
> main two problems are (to be done) initrd loop-mounting in order to do
> klick-on-desktop installs and (existing) problems with live-installer.
I'm talking about having a working product for lenny, so both your use cases
matters although I see click-on-desktop at a lower priority.
> > I'm afraid I could not help more, but I need to program how to spend time
> > precisely, and my priority are on creativity (scratch the hitch) and bug
> > fixes. I really would enjoy more freedom in merging other code, strict
> > rules need time and effort to adhere, and there are diminishing return in
> > really using a cvs so precisely like you seems to enjoy (look latest 3
> > commits, spaces, copyright and a version number... )
> 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 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.
> things have changed
> from a svn where you could commit and i cleaned up afterwards to a
> 'always clean state' git repository done right. please accept that.
Hey, hey, It was not me that did a lot of commits without commit messages at
the times... :-)
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.
> > No critics, but please discuss without prejudice.
> i don't have prejudices, really.
So please, this is not a battle for this particular commit, just that I'm
scared about the your concepts of "cleanness", separation and "uglyness" 
and "beauty"  required for future work.
I just would like you to relax a bit your standard and try to be a bit less
dispotic. Not always one can rebase and split things asking you how do you
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!
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, but I changed it without discussion to
have the code merged in the few time I had) ask if needed , but I think you
could agree with me that I was trying to fast satisfying you to have a fast
So, as I stated before and in the past, you are The Boss(TM) for a lot of good
reasons of work, time, resources spent and passion; I will adhere to your
will, but please look at my points. Some of them could makes sense, read them
I really hope we could find a way in the middle even if I'm not on IRC
fulltime anymore. I enjoyed and I begin to enjoy debian-live work again.... if
you remember well, the first working script was still wrote by me and you'll
surely remember the first chaotic but sparkly phase when features were added
costantly. So It is my son too (even If I had to leave my family soon... for
the real kind of family, you know).
 Uglyness is relative to one's personal tastes, uniformity is not.
 vi /usr/share/doc/linux-doc-2.6.25/Documentation/CodingStyle.gz +237
should be mentioned too although is C related, Chapter 4: Naming.