[openbiblio-dev] Development code in the repository

Wed Jul 7 02:42:25 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In a conversation slightly off to one side in which Will was  
encouraging me to hit the commit button...

On 5 Jul 2010, at 20:29, William Waites wrote:
> I just want to re-iterate this. We have no systems running this
> code that can be considered production or mission critical,
> and if we did we'd just make sure to have some stable releases
> for them to run off of. Please don't be shy about pushing stuff
> to the repositories!

The current trend definitely seems to be moving towards maintaining  
repository code that passes all (or at least, all significant  
functional) tests --- even better if it executes coherently.

Pylons is one example and Chris McDonough of Agendaless/repoze/bfg  
also adopts this stance. It's becoming rare to find extensive test  
failures or nonfunctioning development code in repositories, partly  
due to increasing use of TDD and partly due to the popularity of  
repository arenas such as bitbucket, github and friends. The (often  
smooth) functioning of development code checked out of public project  
repositories is increasingly being viewed as something of a hallmark  
of engineering design quality.

Granted that this approach is a tad more taxing on development but it  
leads to a much more positive experience for early adopters. From the  
persepective of the developer, the more the code is exercised and used  
the more likely that any design infelicities/opportunities are  
revealed at a usefully early stage - as well as bugs being exposed. It  
also seems conducive to the development of a rich user/developer  
community. I find it interesting that Ben Bangert rarely needs to post  
answers to questions on the Pylons email list; the Pylons community is  
generally self-catering in that respect.

I've spent most of today in marginally-productive work: getting a  
clean install of Bibliographica on a VMWare-hosted fresh base install  
of Jaunty Jackal in order to confirm that the Pylons 1.0 version of  
openbiblio passes all the tests. (My PowerBook carries so much Python  
and SemWeb code that I simply cannot tell whether confounding code is  
in play).

I'm a little concerned at the amount of detailed effort and technical  
knowledge required by the Bibliographica install process, it does seem  
to make significant technical demands of the installing user. Perhaps  
Jaunty Jackal was a poor first choice for me to make for a candidate  
Linux VM but it certainly isn't inappropriate.

The wiki reports the requirement: "Data import from bibliographica  
central into local instance"
as arising from the use case: "I do a search on a large catalogue and  
then import results into my bibliographica instance" which in turn  
indicates that end-users are expected to be able to effect a local  
installation.

Still, ultimately I was successful and I can confirm that Openbiblio  
now requires Pylons 1.0, 21/21 tests pass and the commits have been  
made.

I maintained notes of each step in the process in order to add to the  
HOW-TO document and in the process I have also been able to include  
init.d scripts for 4store and xapian process management.

The next stage is to distil the notes into a set of cut'n'paste- 
exercises-cum-shellscripts specialised for a base installation of  
Jaunty Jackal. This then should be fairly readily adaptable for use  
with Karmic/Lucid and Centos/Fedora and, w.r.t. the Python packages,  
install documentation for Windows and OS X.

- --
Cheers,

Graham

http://www.linkedin.com/in/ghiggins

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkwz6ZEACgkQOsmLt1Nhivyy+ACeIs+KES35DZuSqeiiQXkHXnhS
Mr8An1zheAhMDQqjND8dkMy5cd4UvgFUiQCVAgUBTDPpkVnrWVZ7aXD1AQIbYgQA
yLiHqRnbNGrwwE1I1IyQzkzjZh359q2FjIGUPN6OcqnBaaiRfVTrYc8gURJTOjC7
NZKVVLG4hCVobo6SYfm/2FvgjCzlOT4xeuwJEo09KOFvCJJ5TJu9LdsUsRsXO7iI
e2ZAclfq13um0u2uPgIako1mdFIj0A3WoYnN/b0Suoo=
=vPvj
-----END PGP SIGNATURE-----