[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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[0] 
coding style: 
$ grep -e '[::alpha::]* ()' scripts/live
Arguments ()
is_live_path ()
matches_uuid ()
get_backing_device ()
match_files_in_dir ()
mount_images_in_directory ()
is_nice_device ()
copy_live_to ()
do_netmount ()
do_httpmount ()
do_nfsmount ()
do_cifsmount ()
do_snap_copy ()
try_snap ()
setup_unionfs ()
check_dev ()
find_livefs ()
set_usplash_timeout ()
mountroot ()

$ grep -e '[::alpha::]* ()' bin/live-snapshot.old
Error ()
panic ()
Header ()
Help ()
Usage ()
Version ()
Is_same_mount ()
Parse_args ()
Defaults ()
Validate_input ()
Mount_device ()
Do_snapshot ()
Clean ()
Main ()
$ grep -e '[::alpha::]* ()' bin/live-snapshot.new
handle_error ()
panic ()
header ()
help ()
usage ()
version ()
try_refresh ()
parse_args ()
defaults ()
validate_input ()
mount_device ()
do_filelist ()
do_snapshot ()
clean ()
main ()

So , IMHO things are not consistent as it was, I just, while adding a feature, 
fixed that (uglyness)[0] non uniformity. [1]

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 [0], 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. [0] 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" [0] 
and "beauty" [0] 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 
want things.

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).

[0] Uglyness is relative to one's personal tastes, uniformity is not.
[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.

Reply to: