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 () -------------------------- mine: $ 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 merge. 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 carefully. 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. -- ESC:wq _______________________________________________ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
