Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1420#discussion_r60284224
--- Diff: packaging/centos7/cloud-management.service ---
@@ -24,6 +24,7 @@ Description=CloudStack Management Server
After=syslog.target network.target
[Service]
+UMask=0022
--- End diff --
@rafaelweingartner I'm sorry, I don't intend to be rude to you. Bear in
mind, I'm doing this after hours in my free time as you are reviewing in your
free time; I'm tired and exhausted and I just want to see things move. I'm
embarrassed hence the facepalm.
I'm trying to help you here, I've shared a list of things (in a comment
below) that you can find useful and improve on -- kind of reviewing the
reviewer, and it's fine with me if you disagree on things I suggested.
This is my experience and view (and the view in not specific to you but
reviewers in general) -- In an opensource community, we need to know the kind
of expectation we can have from PR authors. For this specific case, it's
alright that someone did not understand something, but PR author is not
responsible or required to explain how xyz works, in this case how systemd
scripts work especially when you can read the documentation. In ACS specific
community we take reviews seriously and PR generally get blocked unless
outstanding issues get resolved, and in a way that holds the PR author like a
hostage where they either fix it the reviewer's way, or reach a compromise or
have his contribution rot. This general ends up wasting three people's time --
the author, the release manager (wherever applicable) and the reviewer; and
time wasted when something (like this) may become a bigger issue than what was
intended in the first place. Lastly, when we're working in globally distributed
timez
one it adds a drag, momentum is lost and we lose contribution pace or
something interest.
To give you a background -- last month, we saw sort of a CloudStack
"ice-age" where not a single commit was committed/merged for more than 30 days.
I received emails from users asking if the project is dying. I figured what I
can do to fix this, I fixed Travis so we've a faster way to check PRs. We also
want to be pragmatic to PRs and avoid wasting time, or dragging over issues.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
