[OPEN-ILS-DEV] Developer meeting 2011-11-01 - agenda / discussion items?

[Dan Scott]

Assuming that we'll have quorum for a meeting today (in a few minutes or
less), here are a few things that we might want to discuss:

Evergreen 2.1.0 - we need to 1) announce that it is available and 2)
announce that the 1.6 series is not expected to receive any further
community support.

Also need to work out when a 2.1.1 release can come together, there are
a number of bug fixes that have been applied (and some waiting on merge
requests) that IMO justify a release real soon now...

Google Summer of Code Mentorship summit report: I attended the GSoC
Mentorship Summit approximately a week ago, and have a few fairly
general suggestions that came out of meeting with tons of mentors from
other free software projects:

1) To encourage new contributors (such as students, but including the
broader community) to continue to contribute to your project, treat
their contributions like you would treat their baby... it is special, it
is beautiful, it deserves care and feeding before you do. If the
contribution doesn't meet your coding standards or needs some fixes
before it is applied to the code base, make those fixes yourself and
provide that as feedback, along with thanks and encouragement to the
contributor, rather than forcing the contributor to rework their patch.

In short: lower the barriers to participation. (I've certainly been
guilty of being too pedantic in the past, so this was a particularly
personal takeaway for me.)

Also: we probably erred by creating special repos for our students this
year rather than treating them as regular contributors who should be
pushing branches to our regular "working" repos. Lesson learned for the
future.

2) As a corollary to #1, the barriers to participation and committing
patches to the master repo with minimal delay can be reduced
significantly if you have test suites that you can run to ensure that
the patches don't break your existing functionality. Test suites are
also crucial when you want to refactor parts of your project to ensure
that your outputs still match your inputs (say, for removing
dependencies on deprecated packages like CDBI 3.0.1). We have the
buildbot environment in place to support unit testing, at least, but
we have very few tests - and we really need testing at a systems level
as well. I have to admit to being stumped as to how to make progress on
this front, as it seems to require either a fairly broad commitment from
contributors or extensive focus from some dedicated testing resources.

3) A number of projects recommended replacing autotools with cmake as a
more modern / usable build system. I spent some time putting together
a prototype of what OpenSRF would look like using cmake and (so far as I
got) it seems cleaner; I'm not convinced that it justifies a complete
rewrite of our build system though. And there's the matter of a lack of
tests (see #2) to ensure that none of the build flags were mangled
during the rewrite. (The branch containing my efforts thus far, such as
they are, is in the OpenSRF working repo at /user/dbs/cmake)