Is there anything *enjoyable* about our development process?

Chris Shoemaker c.shoemaker at cox.net
Sun Oct 16 15:11:23 EDT 2005


On Sat, Oct 15, 2005 at 04:50:51PM -0400, Josh Sled wrote:
> On Sat, 2005-10-15 at 14:23 -0400, Chris Shoemaker wrote:
<snip>
> > 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. :)

I don't think so.  Healthy projects go through evolutions of far more
dubious value than the G2 port, and don't end up rotting at all.
Anyway, even if you're think of some of the other,
...ahem.. infelicities, of the codebase, it at least builds and that's
not even close to terminally broken.

> 
> 
> > 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.  

I agree about the negative feedback, and about striving for quality.
But generating code that results in negative feedback is way better
than generating no code, and is beneficial.  And if the feedback loop
is such that code development is damped to a trickle, everyone loses.

> Breaking the build is still a waste of time and
> resources, even if not as much as before.

But in the total analysis, breaking the build because people are
actually writing code but making mistakes is much better than never
breaking the build because no one wants to write any code.

> 
> 
> > 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.

> The "dropped by
> distros" part is due specifically to a *lack* of development, not
> chaotic development.  

Yes, that's what I meant to imply.

> 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). 

I think I'd dispute the parts about casual patches and external
contributors.  I think it's >95% regular developers, but whatever...

> But below I'm going to assume that the
> small set of developers is actively developing.]

But even the *active* development of a just a few developers may still
be insufficient to adequately maintain a project as large as GC.

> 
> 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.

Well, considering that having something that "works" may require no
code at all, and having people write and *share* broken code means at
least code is being written, I think submitting broken code is more
useful.  But note, I don't think I have the same view of "submission"
as you do.  I pretty much just mean that it's been written and more
than one pereson has seen it and evaluated it.  Even if it's broken
code, I don't necessarily connote anything like 'breaking the golden
build'.

> 
> 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.

Again, I have to disagree.  Having developers with different styles
and desires is just a FACT of OSS life.  Do you think other projects
of gnucash's size have some monolithic development community with
singular vision and style?  I think what got GC into its current state
was how developers *responded* to the above fact.  (BTW, this *is* a
criticism, but it's not so much a criticism of any individual
developers as it is of the developer community as a whole, and I think
we can change our ways.)

> 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.
> 

It's both/and.  And that PITA part comes from several different
sources.  E.g. there's just no convenient forum for saying "look, I'm
starting to make these changes, but this is still rough.  Is this code
on the right track?"  How many posts like that does -devel get?  2 per
year?

> 
> 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. :)

You're right - we agree more than we disagree, but what fun is it to
talk about what's in agreement?  :P

-chris

> 
> ...jsled
> -- 
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`


More information about the gnucash-devel mailing list