Open Stack

Coming from Ops, yes things should always be deployable, backward
compatible and shouldn't break, but at the same time we're talking about a
master branch which is always in flux and not an actual release. I think
that statement you provided Dims should apply to releases or tags and not
the master branch as a whole. And to be honest unless someone desperately
needed something just committed into master, I doubt most folks are using
master in dev let alone production, at least that's my hope.

We can't move forward as a community if we don't welcome new members to it,
which is the heart of this proposal.

Amy (spotz)

On Wed, May 30, 2018 at 2:50 PM, Davanum Srinivas <davanum at gmail.com> wrote:

> Please see below:
>
> On Wed, May 30, 2018 at 2:37 PM, Chris Dent <cdent+os at anticdent.org>
> wrote:
> > On Wed, 30 May 2018, Julia Kreger wrote:
> >
> >> I don't feel like anyone is proposing to end the use of -1's, but that
> >> we should generally be encouraging, accepting, and trusting.
> >
> >
> > Being encouraging, accepting, and trusting is the outcome I'd like
> > to see from this process. Being less nitpicking is a behavior or
> > process change. Adjusting attitudes (in some environments lightly,
> > in others more) so that we (where "we" is regulars in the projects,
> > experienced reviewers, and cores) perceive patches as something to
> > be grateful for and shepherded instead of an intrusion or obligation
> > would be a significant and beneficial culture change.
> >
> > A perhaps more straightforward way to put it is: When someone (even
> > one of "us") submits a patch they are doing us (the same "we" as
> > above) a favor and we owe them not just a cordial and supportive
> > response, but one with some continuity.
> >
> > Like many, I'm guilty of letting a false or inflated sense of urgency
> > get the better of me and being an ass in some reviews. Sorry about
> > that.
> >
> > A cultural shift in this area will improve things for all of us.
> > Nitpicking is symptomatic of an attitude, one we can change, not the
> > disease itself.
> >
> >> We also need to be mindful
> >> of context as well, and in the grand scheme not try for something
> >> perfect as many often do. This *does* mean we land something that
> >> needs to be fixed later or reverted later, but neither are things we
> >> should fear. We can't let that fear control us.
>
> Let me poke at this a bit. Some of the projects do say (not in so many
> words):
>
> "master should be always deployable and fully backward compatible and
> so we cant let anything in anytime that could possibly regress anyone"
>
> Should we change that attitude too? Anyone agree? disagree?
>
> Thanks,
> Dims
>
> >
> > Yes, very much yes.
> >
> > --
> > Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> > freenode: cdent                                         tw: @anticdent
> > ____________________________________________________________
> ______________
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180530/5e8228e9/attachment.html>