Quoting Luca Barbato (2014-12-07 16:03:51) > On 07/12/14 14:05, Anton Khirnov wrote: > > So fix your vim setup. Reformatting every file you ever touch is a very > > bad practice, for reasons stated in the previous mail. > > My vim setup is perfectly suited for my needs. >
Which would be fine, if you did not try to force your setup on other people. > > Again, this is completely orthogonal to what I'm talking about. Some > > things simply are up to people's personal preferences. I very strongly > > disagree with automatically reformatting code with some tool all the > > time. > > Let me explain better: > > - I need to read the code, crufty code for me is unreadable. Are you saying that code that does not have perfect vertical alignment everywhere according to your personal rules is unreadable for you? Then I have to wonder how can you read anything anywhere. > - I have an automated means that makes it readable to me The opinions on the effect of vertical alignment on readability vary wildly. I personally think it significantly helps in some cases and has a mildly positive effect in most other, but certainly not all. I am however very sceptical about using automatic tools for vertical alignment, because "readability" is hard to define precisely. Furthermore I know that some people involved in this project have different opinions on this and we currently have no hard rules. You absolutely should NOT invent new rules on your own and try to force them on everyone. Especially since you are not even touching the code in question (at least right now). I would have no objections if you changed formatting slightly while doing other work on the code, but that's not the case here. > - Even if automated, it is an unnecessary waste of my time redo it every > time I have to read it again, thus a patch is provided. A patch changing the code you do not modify otherwise according to your preferences. Now imagine what would happen if everyone else did it. > > >>> Of course fixing horribly formatted unreadable files from 2003 is good > >>> and just, but that is certainly not the case here. So please, no > >>> unnecessary cosmetics unless you actually touch the code in question. > >> > >> Dropping this patch forced me to redo the second. > >> > >> Soon I'll start sending some chunks of security fixes (since Google > >> kindly provided me another batch of samples exercising faulty code) and > >> I will need to clean the code I'm reading, I hope you'd not force me to > >> redo 200+ patches or have me drop patches cleaning code that I have to > >> read to track where the actual problem is. > > > > 1) This just reinforces my point of avoiding unnecessary cosmetics, > > since it breaks other people's work in progress for no good reason. > > If other people work collides with mine I normally just rebase my > changes and do not complain. So do I, yet the point still stands. One should not make life harder for other people, if it's easily avoidable. Which it is. > > > 2) You should not be hoarding 200+ patches, unless they all depend on > > each other. For exactly this reason. > > The 200+ is the estimate from the ~600 samples I got (on average a patch > solves at least 3 samples), it would take me on average about two weeks > of my free time to complete that set alone so I wouldn't expect to come > up with more than few patches in the next weeks if nobody helps. Then I have no idea what your original comment was about. If those patches do not exist yet, then there is nothing to conflict. And I really hope you do not seriously intend to add cosmetics to every single security fix. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
