On Sat, 2005-10-15 at 14:23 -0400, Chris Shoemaker wrote: > I think you may have missed the essential point. It's not the variety > (or lack thereof) of code management techniques. It's the > burdensomeness of *code management* tasks.
I didn't miss the point, I've been complaining about the overhead of this for a while myself. Neil said that everyone does everything differently, and that that is a problem. I just don't think that everyone *does* do everything that differently. Now I'm curious as to specifics, though. > Furthermore, GnuCash is at *far* greater risk of rotting than it is of > being terminally broken. Interesting, as my arguement is that it is currently rotting because of terminal breakage. :) > Once you remove (or sufficiently reduce) the pain of code-breakage > imposed by ancient version control, then NOTHING BUT GOOD THINGS can > come from all those actions. Breaking of conventions leads to people > better understanding the underlying motivations for the conventions, > and sometimes, it leads to better conventions. Sharing wild new ways > of doing things leads to a greater appreciation of the tried-and-true, > and sometimes, it leads to a new best way of doing something. > Defending code or a method leads to better understanding of its > strengths and weaknesses. ALL of these outcomes have collateral and > immediate BENEFIT. No. Not *nothing* but good things; there are drawbacks. Let's seperate out "if we never try novel ways of doing things we never grow and evolve our techniques", because I'm not talking about that. I think that's healthy and good, even if I don't think it should necessarily germinate in a project like gnucash. I'm not against whole new features, wholesale replacements of existing features, or even adopting paradigms like QOF, &c. I'm talking about things on the small/medium side: replacing spaces with tabs, gratiutously adding code in style B to a file that's 90% in style A, committing code that only compiles in a narrow environment, unfinished infrastructure changes, &c. All I'm saying is that there should be a negative feedback loop about that. People should be encouraged *not* to do it, even if the version control system makes it easy to get out of those states. People should strive for quality, not whatever just works. Breaking the build is still a waste of time and resources, even if not as much as before. > 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. The "dropped by distros" part is due specifically to a *lack* of development, not chaotic development. As well, a lot of the actual progress toward getting the gnome2 port done has come from casual patches and external contributors (and David Hampton). But below I'm going to assume that the small set of developers is actively developing.] Of *those* two options I'd rather have (1). The goal is *not* to get as many developers and/or commits as possible. The goal is to produce working software. Lots of developers generally makes that more possible, but not necessarily. So if the options are a small number of safe developers or a large number of commits that don't compile/are buggy/don't work everywhere/&c, I guess I'd rather have (1). But of course I want a mix of (1) and (2). I don't think allowing any random checkin from anyone *necessarily* creates great software, nor do I think that rejecting a patch with comments because it does something too-strangely *necessarily* doesn't do that. I think there's value in maintaining the internal consistency of a large program by having rough consensus and direction, and that means saying "no" sometimes. I don't think it's as useful for someone to spend the time to develop commit a bunch of code that the other developers disagree with architecturally or design-wise, and thus have to spend more resources either buttressing or exterminating, vs. discussion and concensus up front. Certainly prototypes can help discussion and thus concensus, but that's different than commits without prior agreement and/or needing defense. I don't think it's as-useful for people to submit broken code (or to break existing code) as it is to have something that works, but I also don't have a problem with patches that aren't quite finished going in the tree so that people can more easily collaborate on them. I also don't think GnuCash as a project would reject such as patch as a rule. Having many different developers over time with varying styles and desires is part of what got the project into its current state. So, no, I don't think that that is necessarily its salvation. I still think the reason patches aren't coming in is not because people can't submit patches, or because they can't do `cvs commit` ... it's because the code is too complex, hard to understand, and it's a PITA to develop the changes in the first place. In any case, I think we're mostly in agreement about this, and I look forward to making this a better project for ourselves and others to work on. :) ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
