: It might place too much onus on the release manager to have a dev environment : setup up for every client language possibility. While the ruby stuff might be : simply an inconvenience, there are also php and .net clients out there, and : the total volume of hassle rises considerably.
ideally every client should support a consistent build and test interface, similar to the way lucene-java contribs work, so that regardlss of what build tools they use, you can say... cd clients/foo/ ant compile ant test ant dist ...and it will do the right thing at each step. if you don't have a dependency needed to perform a step (ie: no .Net compiler, Rake not installed, etc...) then it would fail. Clients should be built as part of the automated build system and tested against the version of Solr in the same commit -- so we'll know instantly if someone commits code to Solr that breaks an assumption in the client, even if that commiter doesn't have the ability to test that client themselves. This assumes that the machine running the automated build has all of the tools neccessary to build every client -- if that machine is the lucene zone, then all we have to do to make official releases feasible is to make sure whoever volunteers to be the release manager has a zone account. Things get tricker if we start adding clients that cannot be built on the zone at all becuase of platform issues (ie: Visual Basic on solaris?) but in that case then Mike's delegating idea makes sense ... except that it's a little more complicated then just waiting for the lead dev of the client to say "all clear" we would need people to actaully build the clients and upload the binaries to be included in the release. (or i suppose we could start taking the route that only the server will be released in binary form, and clients will be released as source) it would probably be worthwhile to see how groups that produce binary releases for multiple platforms (ie: httpd) handle stuff like this... : I think this can be delegated (assuming apache bylaws allow this). The : release manager would prepare a release candidate for evaluation, and wait for : the "all clear" from the leads for all clients that they couldn't test : themselves. If no one is willing to do this evaluation work, then we should : drop the client from the distribution. -Hoss
