On 29.07.2013 22:36, Christopher Schultz wrote: > Rainer, > > On 7/29/13 1:22 PM, Rainer Jung wrote: >> On 29.07.2013 17:26, Nicholas Williams wrote: >>> On Mon, Jul 29, 2013 at 10:18 AM, Christopher Schultz >>> <ch...@christopherschultz.net> wrote: > >>>>> If it's a resources limitation, I have a publicly-accessible >>>>> TeamCity server with an unlimited OpenSource license hosting >>>>> Windows 7, Mac OS X SLeopard/Lion/MLion, Debian, RedHat, and >>>>> SuSE agents that I would be happy to donate some resources >>>>> from. It's not very busy and would have plenty of time to run >>>>> CI, SNAPSHOT, and RC builds for all of the platforms. >>>> >>>> No, the problem is that there are so many different >>>> combinations of platform, environment, etc. that it would >>>> represent an explosion of options that would never meet >>>> everyone's needs. >>>> >>>> Building mod_jk just isn't that difficult. The only legitimate >>>> complaint that I have heard is that most responsible admins >>>> don't have a build chain available on a production server. We >>>> solve that by building on a test server and pushing the >>>> binaries out to our production servers. Others may do other >>>> things. >>>> >>>> I do know that Debian-based distros of Linux can install the >>>> "libapache2-mod-jk" package, though it is often out-of-date >>>> with respect to the currently-available version. Inexplicably, >>>> Red Hat does not provide mod_jk binaries through their package >>>> manager. I'm not sure about Suse and others. >>> >>> Understood. I don't know about others, but SuSE DOES provide >>> mod_jk in their package manager. That's how I installed it. Even >>> so, it's rarely even close to up-to-date. Usually about a year or >>> two behind. > >> We had times where we did provide some Linux binaries. Development >> for mod_jk has slowed down, many distributions contain a reasonable >> version of it and no one in the team is really interested in >> providing binaries so it wasn't a priority. It surely is a mixture >> of time and technical resources but probably even more we don't >> feel it's an important itch to scratch. > >> I wouldn't oppose if someone stood up and wanted to provide >> binaries, but it should be someone in our web of trust, because we >> can't validate binaries we get from outside. So we don't want to >> officially distribute contributed binaries. > >> If there were such a person, she might happily comeback to your >> offer concerning build platforms though the ASF has quite a few >> build servers as well. > > Don't forget about the long internal argument(s) about building on > untrusted machines, etc. How far does the ASF trust its contributors > to produce binaries?
That's why I wrote "someone in our web of trust" and "So we don't want to officially distribute contributed binaries." ;) Typically our web of trust would mean "committers", but in some situations it might be a slightly different group. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
