Is there anything *enjoyable* about our development process?

Richard Mancusi vrman49 at gmail.com
Fri Oct 14 15:58:21 EDT 2005


I don't suspect this will mean all that much but - all of your
work is appreciated.  This project is VERY important to the
Linux community.

As for the effort and G2 port - I feel your pain.  This is exactly
what I am doing now.  Actually, as I write this, I have strace
running trying to figure out what the heck the app is doing when
it sloooows down.  It takes most of the day to get there and my
strace file is at 40MB and growing.  This will be interesting.

Enough of my problems - you get the picture.  Please don't
forget how much you folks mean to the entire Linux community.

tnx
Rich

On 10/14/05, Chris Shoemaker <c.shoemaker at cox.net> wrote:
> On Fri, Oct 14, 2005 at 07:56:36PM +0100, Neil Williams wrote:
> > On Friday 14 October 2005 6:53 pm, Chris Shoemaker wrote:
> > > I recently came across (via /.) a brief 1-page article titled "-Ofun":
> > > http://www.oreillynet.com/pub/wlg/7996. I agree with the author's
> > > thesis, which is that optimizing a project's development process for
> > > the pleasure of developers leads to all sorts of good things.
> >
> > Very interesting article - each objection is countered and he makes a good
> > case. Personally, I've found the "fun" being drained out of my gnucash
> > development because of the pressure to get G2 out. There are too few
> > developers and gnucash development itself, IMHO, is currently not much fun at
> > all.
>
> I feel the same way, but I don't think it's because of any pressure
> related to G2.  I think it's more just the whole painfulness of the
> whole process.  I'm trying to pin down exactly what that includes.
>
>
> >
> > Nobody wants all this again with Gnome3. Something needs to change. I fear the
> > loss of a "community" feel to gnucash.
>
> User community or developer community?  Because I'm not sure I'd call
> this a "developer community".  More like a small group of over-worked,
> over-tired, long-suffering, obstinately-determined coders desperate to
> have a decade's-worth of code not rot into oblivion.  I don't
> know... an image of a pack of drowning rats just popped into my head.
> :)
>
> >
> > During my short time in gnucash, I've had contact with two possible new
> > developers who have decided not to pursue their interest. Various reasons are
> > given but the sense is that they have simply found something better to do
> > with their time. Something that is more fun, more involving and provides more
> > positive feedback may help to retain at least some of these people.
> >
> > How many of us have similar experience?
>
> Well, it's not for the easily depressed, but if you read -devel
> archives, you could probably come across ~50 of those over the past 5
> years. :(
>
> >
> > > As applied to GnuCash, I would make a stronger assertion, though.  I
> > > believe that GnuCash's continued progress and relavence, absolutely
> > > *depends* on a drastic revamping of the development process.
> >
> > I agree.
> >
> > What about this bit:
> > "Continuously push the team to sketch out ideas in code, committing quick and
> > dirty protypes that can be refactored as they grow."
> >
> > Quick and dirty prototypes may well break the overall build - I saw little in
> > the article about whether this was a problem or whether such a principle is
> > outdated by the move to a different version control method.
>
> Not outdated.  In fact I think maybe this technique almost *requires*
> a version control with quick and easy branching.
>
>
> > The only
> > reference is v.brief:
> >
> > "Having this safety net allows the project to run full-bore without
> > time-wasting process getting in the way, and without undue worry that code
> > quality will suffer."
> >
> > The basis of the article is experience with the Perl6 compiler - a large and
> > complex project like that should mean that the benefits can be transferred to
> > our complex gnucash build.
> >
> > However, the devil may well be in the detail. By definition, people interested
> > in a Perl6 compiler will tend to be other developers. Although gnucash-users
> > generates lots of wishlists and ideas, there aren't that many developers
> > coming our way. Our userbase is fundamentally different from the example in
> > the article.
>
> True, but the claim is that the project's success was due to the
> pleasant development process, not the project's content.  I think it's
> a reasonable claim.
>
> >
> > So with limited numbers of possible new developers available, we aren't doing
> > a good job of encouraging their contribution. That needs to change.
>
> I agree, but I would say it differently.  Let the pleasure of
> development be its own encouragement.  We just need to remove the
> sources of *dis*couragement, i.e. the pain currently associated with
> development.
>
> >
> > > Fortunately, I don't think this will require much innovation.  We can
> > > simply emulate the many projects that are thriving, attracting new
> > > developers, etc.  However, I do think it will require a lot of
> > > initiative on our part.
> > >
> > > Does anyone agree?
> >
> > Yes.
> >
> > > If so, I'd like to start discussing what concrete things we can do to
> > > improve the whole developement experience, considering ideas from the
> > > article and elsewhere.
> > >
> > > E.g. Would a modern version-control system improve the development
> > > experience?  (It seems like several of the other recommedations in the
> > > article depend on it.)
> >
> > By modern do you mean SVN or something more like GnuARCH? I've had a nasty
> > experience with gnuarch but I'm willing to give it another try. The problem
> > was that until the arch setup is well understood, it's a steep curve and the
> > confusion is immense. Simple failings in the "checkout" and "login" type
> > procedures are not handled gracefully by the current front ends - the errors
> > are misleading and unhelpful. The very fact that there are two front-ends
> > with different command sets is hard enough.
>
> I don't know what a good choice of version control would be.  But I do
> know that if the version control is painful to use/learn, it pretty
> much doesn't support the goal of reducing pain.  That said, I'm pretty
> close to desperate enough to try anything that looks promising.
>
> -chris
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



More information about the gnucash-devel mailing list