Hi Alex, On Thu, Jul 25, 2013 at 03:16:16AM -0400, Alexander Smirnov wrote: > This series looks too much extended. The big part of patches really make no > sense, why can't you fix all comment-related in one patch, all bit-handling > in another, what's the idea to break this stuff in lots of small patches? > 6lowpan is just one file in the kernel, and you are going to apply 14 > patches - increase history for 14 commits. Going this way, kernel becomes > more and more tangled. No no no, lets hold in respect other hackers who > will work with 6lowpan. >
okay, I can do a 'remove 6lowpan implementation' patch and a patch 'add rewritten 6lowpan implementation' patch. To make many smaller patches it's easier to review these patches and we have a good view over all changes. Of course I can squash some commits there, like "Check on CID, SAC, DAC" bits or the comments fix... but what is the case in patch "6lowpan: handle only real local link addresses" should I fix the comment at first and then fix the implementation. The important thing is that the code need to be "bisectable". That can be done with smaller patches or big patches. If we apply smaller patches a guy how run "git bisect ..." can say commit xyz breaks 6lowpan implementation in some cases. With a big patch it can be everything! I don't know how I should deal with that..., normaly persons say to me that I need to split my patches in many smaller patches. Maybe I make more patch series, a patch series to fix only uncompression of addresses, one with comments fix, one with ... and so on. I would prefer this procedure. Let me know your opinion. Thanks for you reply. - Alex ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
