Sorry, Jim; I'm old and forgetful :) In any event, there something to be said for lettting Bamboo build our JARs on every checkin, and so forth.
My suggestion would be to ask Mark to set this up, link to it, and if goes well, we can turn the S2 nightly builds off again. -Ted. On 8/14/07, James Mitchell <[EMAIL PROTECTED]> wrote: > I don't know how many different ways I have to say this to make it > stick. > > -== I am *NOT* running any automated builds on my own machine ==- > > That covers the terms "local machine" and "personal machine". > Everything is done on ASF hardware. > > > The ASF provides us (The Apache Struts Project) with a Solaris Zone > [0] that we happen to use to do the automated nightly builds with. > Any committer has a right to ask for an account on this box. > > [0] http://www.apache.org/dev/solaris-zones.html > > > If you guys still feel that you do not need the process that I have > in place. Please let me know and I'll stop the cron job. > > Thanks. > > > -- > James Mitchell > > > > On Aug 14, 2007, at 8:43 AM, Ted Husted wrote: > > > On 8/14/07, James Mitchell <[EMAIL PROTECTED]> wrote: > >> You know, there's nothing wrong with what we have now. > >> > >> Besides, you'd have to have an account on the ASF box in order to > >> drop the jars out there and I am -1 on keeping my private key on a > >> box (other than my own personal machine) out there that is not owned > >> and managed by the ASF. That probably breaks some ASF policy anyway. > > > > I believe the idea is that we would simply link to the location where > > Bamboo is keeping the JARs, not unlike the way we link to resource > > like Biblio and Nabble. > > > > From a policy perspective, this solution is preferable since it > > distances the PMC from the snapshot builds. Under the Apache License, > > someone building these JARs for us is a perfectly acceptable use, so > > long as there is not a representation that the JARs are an ASF > > release. (Which I'm sure there would not be.) Moreover, it means that > > James M does not need to expose his credentials to an automated > > process on his local machine. > > > > From a technical perspective, this solution is preferable since the > > JARs would be always up to date. Immediately after committing a patch, > > the new binaries would be available for volunteers to test. With a > > nightly build, we might have to wait until the next day for the latest > > JAR to be available. Moreover, Bamboo is building the JARs anyway, so > > this solution is more efficient. It also ensures that any interim > > tests are against the very same JARs that Bamboo is reporting to us as > > successful or not successful. > > > > I'm very +1 on this, since it > > > > * relieves us from the busy work of maintaining the latest build > > JARs, > > * provides an more effective and efficient technical solution, and > > * aligns with ASF principles and policies. > > > > -Ted. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
