On Tue, Mar 12, 2013 at 01:34:54PM +0100, Axel Waggershauser wrote: > I thought splitting by type first and potentially by directory second > if it is too big still, would be best because it reduces the burden on > the reviewer: only one type of change should be easier to skim over > the downside of doing it by type is producing a lot of history noise - commits you need to skip over when you are researching history.
if the burden on the reviewer is too big, then you didn't split it up according to directories/modules sufficiently well. i did this exercise a few years ago already (just to have it discarded), and the outcome wasn't *that* huge (though there were some problem areas, like qtmultimedia and qt3support). > > somebody attempted this just a few days ago, but gave up when the scope > > of the undertaking became clear. i can't find the change now ... > > I don't think the requirement to only accept a patch if it fixes > 'every' whitespace problem in one go would be reasonable as it would > result in exactly this situation: too much work to do/review it all at > once so one gives up. > ok, let's modify the requirement: you don't need to set out to fix every problem. but in the lines you touch because of fixing specific problems, i want to see the remaining issues fixed as well. specifically, i want trailing whitespace and tabs/indentation fixed. the issue you started with is kinda optional for me. spaces around binary operators are kinda secondary, too. i don't even know how big the problem is. > >> b) only do it in files where it is used inconsistently / where the > >> wrong occurrences are the minority? > >> > > no, do it consistently - to have a good example everywhere, and no > > excuses for messing up. then we can make the automatic checking > > stricter, too (which lars said was a precondition for even bothering > > with a cleanup to start with). > > As a final goal, it should obviously be consistent everywhere but I > thought it makes sense to make a difference between files where there > are some random style issues here and there (most of the code) and > files that are written pretty consistently but according to a > different style guide (like the qmake generator stuff). > there are a few projects which have vastly different style (qlalr) or should be excluded out of principle (anything 3rdparty). i wouldn't make an exception for anything else, including the qmake generators (they are seeing incremental coding style cleanups anyway). if you have specific projects in mind, we can discuss. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
