cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bhaisaab <...@git.apache.org>
Subject [GitHub] cloudstack pull request: systemvm: preserve file permissions, set ...
Date Tue, 19 Apr 2016 18:24:55 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message