Brian> It's even more annoying to be deluged with SPAM ;). We
Brian> (the LAM developers) used to try to keep our mailing lists
Brian> as open as possible. In the end, SPAM pushed the signal to
Brian> noise ratio way too high and something had to be done.
Brian> Requiring subscriptions to post was the best we could do.
I understand that you have limited resources to administer your
mailing list, but certainly lists like openib-general and linux-kernel
show that it is possible to run lists with low levels of spam and
still allow posting by anyone.
In general, if I have to subscribe to a list just to send a bug fix to
a project, I'm quite likely to forget about it. So you are definitely
missing out on contributions by closing your lists.
Brian> I'll admit my ignorance - is this part of a particular
Brian> release of OpenIB, or is this something that has happened
Brian> recently in SVN? I ask because we already have people
Brian> using OpenIB and Open MPI together, and it would be bad to
Brian> suddenly break things for them. Testing for number of
Brian> arguments in a function is horribly unreliable - is there
Brian> some version number or other key in the Open IB headers we
Brian> can use to determine which version of the function to use?
OpenIB has not done an "official" release of any userspace components,
so this falls into the category of prerelease API breakage.
New kernels will require a new libibverbs, so the number of obsolete
old development versions should decrease fairly quickly.
- R.
