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 <dava...@gmail.com> wrote: > Please see below: > > On Wed, May 30, 2018 at 2:37 PM, Chris Dent <cdent...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
