On 1/7/19, 1:21 PM, "Allen Wittenauer" <a...@effectivemachines.com.INVALID>
wrote:
> On Jan 7, 2019, at 11:50 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> I don't understand. Who am I "making" do what work? And why do at least
3 others want something similar? And what would you propose Royale should do
instead? Always have me cut releases?
If their computers are broken, they could always spin up a free micro
instance on AWS. Cut the release. Then spin it down.
But it really makes me wonder how they are developing and testing their
changes locally if building is such a burden ...
Building the source code generally works for people. The RM's are having
trouble pushing the built and packaged artifacts to Nexus.
Fundamentally, I am trying to make it easier for our future RM's to cut a
release. Adding more manual steps by spinning up AWS instances or manually
pushing artifacts doesn't seem to make it easier. I thought it would be ok to
ask Infra if we could let a bot make some minor changes to pom.xml files that
are audited before the release is even voted on. Some helpful folks have given
us things to watch out for in those changes. I would rather invest time in
provisioning a shared machine than to try to get people to help debug
intermittent network issues. Folks who are interested in helping us debug
those network issues are welcome to engage the Royale community and the RMs who
had the problems.
To try to summarize where I think we are, the main concern is that someone will
put together a Jenkins task to inject changes to Royale's pom.xml files and
time it with the running of our release job and hope that our reviewers miss
those changes. I agree there is risk there, but is the risk there significant?
If you could run anything on Jenkins would you really attack Royale or run
something else and attack a much more lucrative target?
Greg pointed out the connection between an ICLA and a commit. That made me
wonder: could we get a RoyalePMC committer account? The password and keys
would be shared on the private@ list. I could then provision this shared
computer on the Azure Windows VM I have as part of the free MSDN subscription
from Microsoft. Builds@ would be better since it isn't subject to whether I
continue to get this benefit from Microsoft, but if folks are too concerned
that attackers can run jobs on builds@, what would it take to convince folks
that nobody can run a job on my Azure VM and more than they could remote in to
my laptop and do the same while I'm sleeping? We do not run PR tests on that
VM. And any commits from this VM would come from a PMC member so there is an
ICLA on behind it, although you may not know which PMC member ran the job.
Thanks,
-Alex
