[OpenAFS] buildbot and packages
Fri, 14 Sep 2012 18:46:15 -0400
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
On 9/14/2012 9:12 AM, Troy Benjegerdes wrote:
>>> However, this requires having a much greater availability of release
>>> management and testing resources.
>> And perhaps an argument for automated tests that could prove out a rel=
>> If you mean manual testing resources, given the scope of platform supp=
ort and myriad branches for OpenAFS I doubt 'enough' will ever be enough =
:) If we could bend those resources to creating and maintaining function=
al tests then that might be a better use of time. Definitely a challenge=
> All this talk about 'reliable code for our users' is total BS
> until 'make check' actually does some realistic functionality tests.
> If you can't write an automated test for a feature, then I would
> request we consider disabling that feature.
With all due respect, what group of individuals, companies or
organizations is covered by the above "you"? Based upon your recent
e-mails I assume you mean the OpenAFS Gatekeepers, Sine Nomine
Associates and Your File System Inc.
I believe that everyone on this list will agree that unit tests,
distributed load testing, VFS and IFS kernel interface testing, packet
loss testing, performance testing, error path testing, etc. is important
BUT lets try to put some perspective on things.
The OpenAFS source code repository contains over one million lines of
code from more than 250 developers submitted over more than 25 years
supporting dozens if not hundreds of operating system versions,
processor architectures and distributions.
Of those 250+ contributors only 36 have contributed in the last 12
months. Of those, only eight have contributed at least ten patches.
Here they are with their affiliations and patch counts to the master bran=
12 month All Time
Jeffrey Altman [Your File System] 477 2980
Simon Wilkinson [Your File System] 230 1153
Andrew Deason [Sine Nomine Associates] 162 758
Derrick Brashear [Your File System] 107 1865
Mike Meffie [Sine Nomine Associates] 65 138
Marc Dionne [Your File System / Individual] 49 311
Garrett Wollman [MIT CSAIL] 40 75
Peter Scott [Your File System /Kernel Drivers] 36 36
Other 33 2965
We all know that commits to the master branch are not a direct
correlation to total contribution to the community. There are other
indicators such as mailing list responses, IRC and Jabber responses,
pullups to 1.6 and 1.4 branches, Gerrit reviews, web site updates, etc.
which are not included. However, the commit counts are easily obtained
from Ohloh (http://tinyurl.com/8lvxjph) and identify the point:
There are very few organizations or individuals that
contribute to OpenAFS in significant way.
In the last twelve months there have been 1248 patchsets submitted to
Gerrit and committed into the master branch. The prior twelve months
had 1434 patchsets. That is an awful lot of code to review and much of
that code included unit tests. For a community that is effectively
running on $0 a year, that is exceptional.
Continuing to provide some perspective. The Kermit Project at Columbia
University developed Kermit and generated nearly 700 binaries for each
release of C-Kermit. http://www.columbia.edu/kermit/ckbinaries.html At
its peak the Kermit Project, http://www.kermitproject.org/, had four FTE
responsible for coding, documentation, testing, building, and
distribution. C-Kermit has less than half the amount of code and is
significantly less complex than OpenAFS.
More perspective. The code IBM released as OpenAFS via the
DeveloperWorks site was pretty close to the source code that IBM used to
build the production releases of IBM AFS 3.6 in 2000. I don't know what
the staffing was at IBM Pittsburgh Labs dedicated to AFS at the time but
it was certainly greater than the amount of dedicated staff at the
disposal of OpenAFS.
You have suggested removing all functionality that doesn't have
sufficient test suites. As Mike Meffie points out, most of the
interesting testing is not functional unit testing but load testing,
deadlock analysis, multi-platform interoperability, etc. But more
importantly, code that is included in the OpenAFS distribution is there
because someone probably uses it. Since there is no method to determine
which features are used by whom, OpenAFS does not remove functionality
without a really strong reason. The Gatekeepers do not want to make
upgrading to newer releases contingent upon reworking tooling that
relies upon some feature.
No insult intended to those that came before OpenAFS but the code
quality today is so much better today than it was two years ago, let
alone when 1.4 and 1.2 or the IBM DeveloperWorks releases were issued.
Significant strides have been made in removing warnings from the code
tree thanks to Simon, Marc, Garrett and many others. I think with the
recent libtool work we may finally be getting close to a point where the
mixture of LWP, pthread, and PIC libraries in binaries will be a thing
of the past.
All of the improvements are in spite of the fact that OpenAFS simply
does not have anywhere near the development resources it requires.
You are certainly motivated to produce a product that meets the needs of
your business initiatives. That is wonderful but you can't expect
others to run to assist you simply because you now have a pressing need.
As Tom Keiser wrote to you a few days ago. Start contributing code
that is useable to OpenAFS today. If you want to write tests, people
will jump up and down with joy. However, please do not stomp your feet
and scream that no one is doing anything when Your File System, Inc. has
contributed more than 900 patchsets and Sine Nomine Associates more than
230 patchsets in just the last year. Neither of these organizations
have any obligation to contribute anything and yet both want to see
As a reminder, anyone is welcome to contribute code, documentation, or
other assistance to OpenAFS but there are constraints:
* You can't break the tree.
* You can't submit changes to gerrit that cannot be
reasonably reviewed. It is not helpful to drop ten
thousand lines of code changes in a short period of
time and definitely not in one patchset.
* You can't submit changes that introduce protocol changes
* You can't submit changes that would force OpenAFS to
violate its understanding with IBM such as removing DES
or kaserver from the tree or adding code that breaks
compatibility with IBM AFS 3.4 or later.
When developing, follow the motto:
Discuss often! Commit often!
It is the only way to ensure that your development does not become
trampled by the work of others. At current contribution rates there
more than 100 changes hitting the tree each month. If you maintain a
large number of patches in your private repository you will become very
sad when it is time to merge in upstream changes prior to submitting to
Gerrit for review.
The work that Felix Frank did merging in changes from OSD into the Unix
client is a perfect example of how code should be merged in from an
And finally, have respect for the other contributors in the community.
Trust must be earned. It cannot be taken and attempts to force others
to do what you wish will only result in people tuning you out.
 My e-mail to firstname.lastname@example.org on August 30th
described the four categories from which contributions to OpenAFS are
2. end user organizations
3. support companies
4. product companies
I am not going to repeat why I believe it is unrealistic to expect those
contributors to take on big challengesin this thread. You can read my
prior e-mail (http://tinyurl.com/8myph6a).
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
-----END PGP SIGNATURE-----