I think in this case there isn't a lot of value added relative to the cost. It is an invasive change that doesn't change how easy the code is to work with, and will periodically break things like '\' aligned to the right for continuing macros.
For some things like migrating the mesos codebase style to one which can be as mechanically enforced as possible or resolving. I also potentially see some things like directory moving happening in the future (making it so there isn't a 3rdparty embedded in a 3rdparty). Practically if we are making sweeping changes which will effect everything dramatically, it is a lot cleaner to have one commit which makes the switch, even though it acts as a synchronization point for development, because then it is one commit which gets encountered in a 'git blame' (And you can then do another blame starting at that one commit). On Wed, Oct 15, 2014 at 12:49 PM, Dominic Hamon <[email protected]> wrote: > +1 > > until we get to the point where the out-of-compliance files are minimal, > doing them as we go should be sufficient. It moves the code-base forward to > compliance without being disruptive. > > it does make RRs more complex as there are changes that are not geared > towards the main aim of the patch, but this is still less burden on the > community as a whole. > > On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman <[email protected] > > > wrote: > > > My $0.02: Let's make the cleanups as we go. If you work in a function > that > > can get cleaned up, clean it up. Maybe clean up the entire file if you're > > making changes to multiple functions. Doing this iteratively not only > keeps > > folks from having to do tedious rebases but it also preserves, for the > most > > part, the git blame history which can be invaluable when working in a > file > > and trying to ask for some help. > > > > On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff <[email protected]> > wrote: > > > > > Hey Everyone, > > > > > > I would like to reach out to the developer community for making sure > that > > > we find a consensus on > https://issues.apache.org/jira/browse/MESOS-1872 > > < > > > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire > > > code-base affecting changes. > > > > > > Evelina has bravely proposed three review requests > > > (mesos/libprocess/stout) for covering the ticket. There is however some > > > greater risk involved and I wanted to be sure that we are all aware of > > the > > > pro’s and con's of such big cleanups. > > > > > > + we may need to do cleanups - even major ones at some point, hence I > > > think we need a consensus once and for all regarding tickets of the > above > > > nature > > > - almost all existing RRs will possibly get invalid and everyone with > > work > > > in flight needs to rebase (possibly rather tedious task in particular > > case). > > > > > > There may be more. > > > > > > The only way I can currently see this happening with minimal friction > is > > > finding a certain date and even time for doing this on a very quick, > > > propose/review/commit. > > > > > > What do you think? > > > > > > cheers! > > > Till > > > > > > > > > > > > -- > Dominic Hamon | @mrdo | Twitter > *There are no bad ideas; only good ideas that go horribly wrong.* >
