[openstack-dev] Garbage patches for simple typo fixes

Gary Kotton gkotton at vmware.com
Sun Sep 24 11:35:59 UTC 2017


One thing that we could consider is adding ‘topy’ [i] to our gating. 

[i] https://pypi.python.org/pypi/topy

On 9/23/17, 2:47 AM, "Michael Johnson" <johnsomor at gmail.com> wrote:

    A recent extreme example:
    https://review.openstack.org/#/c/494981/1/specs/version0.8/active_passive_loadbalancer.rst
    
    I would love to have a boilerplate statement I can use as a template
    for things like this.  I feel bad -1/-2 these as I want to encourage
    involvement, but they are a drain on the system.
    
    Michael
    
    
    On Fri, Sep 22, 2017 at 4:18 PM, Zhipeng Huang <zhipengh512 at gmail.com> wrote:
    > Hi Doug,
    >
    > Absolutely glad to help on this matter. We could take this offline first via
    > email or irc chat and then comes up with a solution for the broader
    > community to review
    >
    > On Sat, Sep 23, 2017 at 2:47 AM, Doug Hellmann <doug at doughellmann.com>
    > wrote:
    >>
    >> Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06
    >> -0400:
    >> > Doug,
    >> > Howard (cc'ed) already did a bunch of reaching out especially on
    >> > wechat. We should request his help.
    >> >
    >> > Howard,
    >> > Can you please help with communications and follow up?
    >> >
    >> > Thanks,
    >> > Dims
    >>
    >> Thanks, Dims and Howard,
    >>
    >> I think the problem has reached a point where it would be a good
    >> idea to formalize our approach to outreach. We should track the
    >> patches or patch series identified as problematic, so reviewers
    >> know not to bother with them. We can also track who is contacting
    >> whom (and how) so we don't have a bunch of people replicating work
    >> or causing confusion for people who are trying to contribute. Having
    >> that information will also help us figure out when we need to
    >> escalate by finding the right managers to be talking to.
    >>
    >> Let's put together a small team to manage this instead of letting
    >> it continue to cause frustration for everyone.
    >>
    >> Doug
    >>
    >> >
    >> > On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann <doug at doughellmann.com>
    >> > wrote:
    >> > > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
    >> > >> On 9/22/2017 7:10 AM, Tom Barron wrote:
    >> > >> > FWIW I think it is better not to attribute motivation in these
    >> > >> > cases.
    >> > >> > Perhaps the code submitter is trying to pad stats, but perhaps they
    >> > >> > are
    >> > >> > just a new contributor trying to learn the process with a
    >> > >> > "harmless"
    >> > >> > patch, or just a compulsive clean-upper who hasn't thought through
    >> > >> > the
    >> > >> > costs in reviewer time and CI resources.
    >> > >>
    >> > >> I agree. However, the one that set me off last night was a person
    >> > >> from
    >> > >> one company who I've repeatedly -1ed the same types of patches in
    >> > >> nova
    >> > >> for weeks, including on stable branches, and within 10 minutes of
    >> > >> each
    >> > >> other across several repos, so it's clearly part of some daily
    >> > >> routine.
    >> > >> That's what prompted me to send something to the mailing list.
    >> > >>
    >> > >
    >> > > As fungi points out, education and communication are likely to be
    >> > > our best solution. Maybe one approach is to identify the companies
    >> > > and individuals involved and find one of our community members to
    >> > > contact them directly via email.  We would want the person doing
    >> > > that to be willing to explain all of the reasons the community does
    >> > > not want the sort of activity we are rejecting and to provide
    >> > > guidance about more useful contributions (Matt's comment is a great
    >> > > start on both). I imagine that conversation would take a good deal
    >> > > of patience, especially after the second or third time, but a personal
    >> > > touch frequently makes all the difference in these sorts of cases.
    >> > >
    >> > > If we have someone willing to step into that sort of role, I would
    >> > > be happy to help craft the initial contact messages and advise as
    >> > > needed.
    >> > >
    >> > > Does anyone want to volunteer to work with me and actually send the
    >> > > emails?
    >> > >
    >> > > Doug
    >> > >
    >> > >
    >> > > __________________________________________________________________________
    >> > > OpenStack Development Mailing List (not for usage questions)
    >> > > Unsubscribe:
    >> > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >> >
    >
    >
    >
    >
    > --
    > Zhipeng (Howard) Huang
    >
    > Standard Engineer
    > IT Standard & Patent/IT Product Line
    > Huawei Technologies Co,. Ltd
    > Email: huangzhipeng at huawei.com
    > Office: Huawei Industrial Base, Longgang, Shenzhen
    >
    > (Previous)
    > Research Assistant
    > Mobile Ad-Hoc Network Lab, Calit2
    > University of California, Irvine
    > Email: zhipengh at uci.edu
    > Office: Calit2 Building Room 2402
    >
    > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    



More information about the OpenStack-dev mailing list