Hyrum K Wright wrote on Sat, Jun 11, 2011 at 04:01:07 -0500: > On Fri, Jun 10, 2011 at 7:49 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > hwri...@apache.org wrote on Sat, Jun 11, 2011 at 00:14:03 -0000: > >> +# About this script: > >> +# This script is intended to simplify creating Subversion releases, by > >> +# automating as much as is possible. It works well with our Apache > >> +# infrastructure, and should make rolling, posting, and announcing > >> +# releases dirt simple. > >> +# > >> +# This script may be run on a number of platforms, but it is intended to > >> +# be run on people.apache.org. As such, it may have dependencies (such > >> +# as Python version) which may not be common, but are guaranteed to be > >> +# available on people.apache.org. > > > > Why does the script need to be run on people.a.o? Infra hat on, unless > > there is a good reason, please use some other a.o box for this (eg > > subversion.zones.a.o, also FreeBSD). > > The script does not claim to be required to run on people.a.o, but > rather that it is intended to be run there. The idea is that all the > committers have access to people.a.o, so it can be used as a reference > environment. In other words: "run it on your own hardware if you > wish, if you can't, you can always use people.a.o." >
Fair enough; I missed this distinction. > Though, I must admit that I don't understand the rationale you present > above for *not* running it on people.a.o. It sounds like infra is > saying "don't use people.a.o without a good reason," whereas I feel > that you (infra) should present a valid reason *not* to use it. (A > short search for some kind of acceptable use policy for people.a.o > turned up nothing.) > I'll reply separately. > > Also: why does the script need to be run on a.o hardware? (rather than > > on the release manager's hardware) Using a.o hardware has implications > > on trusting the resulting tarballs in case people.a.o gets broken into. > > One could say the same thing about the release manager's box, and > arguably infra has a better idea of how to secure hardware than some > yokel release manager. :) > Infra is a bigger target than RM's, too. > -Hyrum
