On Sun, 2015-03-22 at 00:42 +0000, Matthew Toseland wrote: > On 21/03/15 20:49, Ian Clarke wrote: > > On Sat, Mar 21, 2015 at 1:58 PM, Matthew Toseland <[email protected]> > > wrote: > >> Most of the above boils down to "review the diff, not the history". That > >> is probably sensible. > > That's part of it, but also that a branch should be created for each > > bugfix/feature, which ideally should be as small a unit of work as possible > > (that can be merged without breaking stuff).
It only is if the diff is of reasonable size... which it is most of the time, *except* when it comes from paid devs. They code in their cave for months, drop a 100kloc diff doing way more than a single feature/bugfix onto the maintainer and expect it to be merged; I'm sure that refactoring is good but not when it's forked off for 6month... This is the problem we had recently with both toad's and xor's code. We're talking about dozens of features and bugfixes AND refactoring. What blocks development is that the refactoring isn't merged until their work is ready... and there's usually a good reason for it; they code first and think later (to be fair it's a common trait amongst devs working alone) which means that as long as they haven't "tried it out" they're not quite sure of what they want in terms of API... so it's only in a mergeable state when "it works". Whether there's a single change per commit/branch/pull request doesn't matter as long as one of them is enforced. Until now the base unit was supposed to be "one change per commit"; I'm all for changing it to something else but that won't solve the problem unless it's enforced strictly. Florent
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
