[clug] Essential Software Practices

[Brad Hards]

On Sunday 01 March 2009 10:00:04 am steve jenkin wrote:
>A little off topic for this list, but it goes to the heart of FOSS & its
>production
(snip)
> What I've come up with:
>
>  - Repository {findable code, user ident, Name Space control}
>  - Version Control {auth, log, diffs, rollback}
>  - Traceability {who changed what, why is a feature present}
>  - Testing {defined repeatable tests}
I'm not sure any of those are absolutely essential, in the sense that they are 
required to do FOSS, or perhaps other "good" software.

> Admittedly the Repo is a 'virtual thing', but setting them up and using
> them is a 'practice'. They support Versioning and the two are integrated
> in 'products' like Subversion and CVS.
The linux kernel didn't have a version control system (in terms of a server 
like svn or cvs) for a long time. Most of the kernel still doesn't have good 
traceability, or automated tests.

> This question came up when I was helping a friend with an Excel
> spreadsheet. It's a real programming environment, but lacks so many
> essentials for good programming its not funny
Most people did kernel development without a debugger. Lots of people still 
don't have what I would consider a decent programming editor (no, of course 
I'm not going to tell you), lots of APIs have little or no documentation (or 
have wrong documentation).

> A really awful experience :-(
I've done some things in excel that really would have benefited from C bit 
operations. I've done things in C that would have benefited from excel 
charting.

I guess there aren't too many things that are "essential".

In terms of making FOSS, I think there are more "principles" that are 
important than particular practices. For example, an open approach to dealing 
with users as participants in the process and less as consumers of the 
finished product is probably a key principle. That might be a practice of 
accepting bug reports on a mailing list, or on a forum, or using a bug 
tracker server/application.

I've had a recent experience with setting up Buildbot. That has some technical 
interest (e.g. as a distributed architecture), some practical benefits (e.g. 
finding out which change broke a particular architecture) and some "human 
nature" effects (e.g. compiler warnings start to get treated slightly 
differently).

Paul has asked me to talk about Buildbot at the next PSIG (in the absence of a 
better proposal). It should be an interesting discussion.

Brad