On Sun, Oct 16, 2005 at 04:20:30PM -0400, Josh Sled wrote: <snip> > > > > 1) A small handful of developers who know all the conventions, never > > > > break the single build, only do things everybody agrees on, and can't > > > > keep their project from being dropped by distros - and no one dares to > > > > join in. > > > > > > > > or > > > > > > > > 2) Several handfuls of developers who have to regularly be corrected > > > > in their breaking of conventions, regularly share code that doesn't > > > > work and has to be fixed, do things that nobody agrees on, but there > > > > are casual developers dropping in all the time and code keeps flowing. > > > > > > [It distracts from your argument to parallel gnucash's recent history in > > > (1), because that's not what we're talking about. > > > > I'm not just arguing abstractly; I'm talking about gnucash. (1) is > > basically the current state of gnucash. > > I know you are, and that it is, but I think it distracts from an > discussion about how development should work; consider how the proposals > change:
Ok, I think I see you point now. "If things were different..." > > 1) A small handful of developers who know all the conventions, never > break the build, only do things everybody agrees on, and release regular > versions. The code is simple enough for casual contributors to > regularly submit patches. Well, I've only seen this happen with projects that are 1) quite small (like could-be-handled-by-one-person-small) 2) quite mature (like this-hasn't-changed-much-since-it-ran-on-PDP11-mature) and 3) have few or no arch/lib dependencies (like you-just-need-/bin/sh). (or at least 2 of the 3). And their development process is *BORING*. :) -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
