On Tue, 24 Apr 2018 10:56:24 -0700 Ken Cunningham <[email protected]> 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 [email protected]
