Sure, but let's not get bogged down with complaining about the past, we all know it's been dysfunctional, let's focus on what we're going to do from now on.
Ian. On Sun, Mar 22, 2015 at 2:06 AM, Florent Daigniere < nextg...@freenetproject.org> wrote: > On Sun, 2015-03-22 at 07:36 +0100, Florent Daigniere wrote: > > 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 < > matt...@toselandcs.co.uk> > > > > 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 > > Just to put some perspective on what I've written above: > > Here's toad's diff: > https://github.com/freenet/fred/pull/287/files > > Here's xor's diff: > https://github.com/freenet/fred/pull/319/files > > in both cases github gives up rendering it: > "Sorry, we could not display the changes to this file because there were > too many other changes to display." > > and doesn't even display the commit count: > " This pull request is big! We're only showing the most recent 250 > commits. " > > As for the individual commits, there's plenty which are doing more than > a bugfix/feature/single semantic change. > > Florent > -- Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
