[openbiblio-dev] Development code in the repository
Graham Higgins
gjh at bel-epa.com
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-----
More information about the openbiblio-dev
mailing list