Open Stack

Sean,

Each fix is a valid change, in and of itself. But what kind of lazy person
would fix (in three patches) the exact same thing, in three places in a
single project?

Or which person would submit the exact same kind of patch multiple times to
change URL's from http:// to https:// in places which are (literally)
comments in the code?

Or submit multiple changes to fix something that is a python stylistic
thing, not enforced by pep8 or some project wide checks for style?
Typically, when I see changes like this, I ask the submitter to make a
corresponding change to the accepted tests (enable an otherwise disabled
change, and show that the tests pass for the whole project). Well, that's
real work and the change gets abandoned.

Those are the kinds of (for lack of a PC word) bad behavior that I think we
should, as a community, reject.




-amrith


On Mon, Sep 25, 2017 at 8:24 AM, Sean Dague <sean at dague.net> wrote:

> On 09/25/2017 07:56 AM, Chris Dent wrote:
> > On Fri, 22 Sep 2017, Paul Belanger wrote:
> >
> >> This is not a good example of encouraging anybody to contribute to the
> >> project.
> >
> > Yes. This entire thread was a bit disturbing to read. Yes, I totally
> > agree that mass patches that do very little are a big cost to
> > reviewer and CI time but a lot of the responses sound like: "go away
> > you people who don't understand our special culture and our
> > important work".
> >
> > That's not a good look.
> >
> > Matt's original comment is good in and of itself: I saw a thing,
> > let's remember to curtail this stuff and do it in a nice way.
> >
> > But then we generate a long thread about it. It's odd to me that
> > these threads sometimes draw more people out then discussions about
> > actually improving the projects.
> >
> > It's also odd that if OpenStack were small and differently
> > structured, any self-respecting maintainer would be happy to see
> > a few typo fixes and generic cleanups. Anything to push the quality
> > forward is nice. But because of the way we do review and because of
> > the way we do CI these things are seen as expensive distractions[1].
> > We're old and entrenched enough now that our tooling enforces our
> > culture and our culture enforces our tooling.
> >
> > [1] Note that I'm not denying they are expensive distractions nor
> > that they need to be managed as such. They are, but a lot of that
> > is on us.
>
> I was trying to ignore the thread in the hopes it would die out quick.
> But torches and pitchforks all came out from the far corners, so I'm
> going to push back on that a bit.
>
> I'm not super clear why there is always so much outrage about these
> patches. They are fixing real things. When I encounter them, I just
> approve them to get them merged quickly and not backing up the review
> queue, using more CI later if they need rebasing. They are fixing real
> things. Maybe there is a CI cost, but the faster they are merged the
> less likely someone else is to propose it in the future, which keeps
> down the CI cost. And if we have a culture of just fixing typos later,
> then we spend less CI time on patches the first time around with 2 or 3
> iterations catching typos.
>
> I think the concern is the ascribed motive for why people are putting
> these up. That's fine to feel that people are stat padding (and that too
> many things are driven off metrics). But, honestly, that's only
> important if we make it important. Contributor stats are always going to
> be pretty much junk stats. They are counting things to be the same which
> are wildly variable in meaning (number of patches, number of Lines of
> Code).
>
> My personal view is just merge things that fix things that are wrong,
> don't care why people are doing it. If it gets someone a discounted
> ticket somewhere, so be it. It's really not any skin off our back in the
> process.
>
> If people are deeply concerned about CI resources, step one is to get
> some better accounting into the existing system to see where resources
> are currently spent, and how we could ensure that time is fairly spread
> around to ensure maximum productivity by all developers.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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/20170926/0222ed8a/attachment.html>