Agility

[Perry E. Metzger]

On Tue, 24 Apr 2018 10:56:24 -0700 Ken Cunningham
<ken.cunningham.webuse at gmail.com> wrote:
> This is a good discussion to have. MacPorts has at times in the
> past bogged down rather impressively with PRs, ticket submissions,
> and updates sitting for so long people lost interest. I know I very
> nearly did.

One thing I've noted in other projects: if it takes too long for
submissions and tickets to be dealt with, people start to feel either
that the project is dead and thus not worth touching, or that their
contributions aren't respected or wanted, and they walk away.

So I've been trying to keep the PR queue short. Whenever anyone tells
me I've done something wrong, I attempt not to make the same mistake
again, and the rate at which I've been yelled at has gone down with
time so I think I'm being relatively successful at learning.

> The policy has opened up clearly, and things are committed now with
> what feels like about 5% of the scrutiny they once were, in 1% of
> the time. This is in part courtesy of Travis, and in part because
> Perry is jumping on them so quickly committing them if we don't
> review them fast enough :>  -- which is great, but feels different
> than how it's been, which is good, but hopefully not bad if
> something breaks, if you get my drift.

Yah, there's a price to be paid for perfection in review, which is
that things stall for very long periods of time.

That said, there are things we can do to make sure review is much
higher quality:

1. We can improve "port lint" -- there are a lot of de facto policies
   it is not currently enforcing, everything from trivia (tabs in
   Portfiles, lack of maintainer github handles) to more important
   things (like dead upstream home pages).

2. We can set up a better CI system than Travis. Travis failures are
   all too often meaningless. In an ideal CI system, failure always
   means "stop", pass often means "go". Right now, passing is
   meaningful (though not as meaningful as it could be), but failure
   usually means you discover that the system just timed out or had a
   bad clock or something. (Note that failures are still useful to
   examine, I've stopped several bad merges because of real failures.)

2. We can encourage more ports to add tests if possible, and we can
   have the CI system run the tests. Automated tests are a lot better
   than hand-checking that something works.

As a general philosophy, I think it is usually better to risk having a
small break rate than having things stall out so long that it is hard
to make progress. Especially in the case of MacPorts, the risk from
breaks is itself relatively small since users can rebuild quite
easily and if we respond to problem reports quickly breaks won't last
long.

The real risk to most users is one we can't mitigate at all. An
upstream can be broken in some bad way that costs someone data, but we
would never know that in the first place, as our quality control
systems are structured around testing our packaging and not the
upstream itself. So the added risk we put people under when we move
pretty quickly isn't very large.

> Most of the new submissions and PRs seem to be working out -- Ryan
> and a few others are backstopping the rather few glaring errors
> very efficiently, and the rest "just work". It feels better. People
> should like it better. It's not a waste of time to submit
> something. I'm getting used to it.
>
> Waiting for the maintainer to review the ticket submission someday
> often resulted in months of nothing happening, or years.
>
> Maybe this is better. I think it is. Is it?

I tend to think it's a better way of working but it's up to the
community as a whole to say if it's really the right way to do
things. (If people really don't like it, I can hang back more.)

Perry
-- 
Perry E. Metzger		pmetzger at macports.org