On Fri, Jun 10, 2011 at 7:49 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> hwright_at_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."
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.)
> 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. :)
-Hyrum
Received on 2011-06-11 11:01:43 CEST