Agility

Mojca Miklavec mojca at macports.org
Wed Apr 25 16:13:03 UTC 2018


Hi,

I just want to say that I find it magnificent what you achieved with PRs.

At the moment there is no single PR older than 4 days and if I ignore
the "add GitHub handle" ones, there are only 9 PRs left (older than
one hour).

Yes, sure, mistakes happen all the time, but they happened just as
well before you stepped in and if mistakes are fixed quickly, this is
less of a problem.

With my first submission I have probably been waiting for about 4
months until the patch was committed. And when someone (experienced)
finally did it, he did not commit it properly (forgotten "svn add")
and left the port in a broken state for about a day and I could not
help. So ... which one is better at the end?

I agree that we should give maintainers sufficient time to respond. If
someone submits a seemingly "trivial" version update to a port which
is not unmaintained, let's keep that 72 hour limit also for
openmaintainer ports. For important/critical closed maintainer ports
the limit may be longer.

Yes, we should definitely strive towards improving our CI testing
methods in various ways. But I would not want to become draconic
strict about merging contributions. The fact that plenty of patches
have been waiting on Trac for 5+ years doesn't increase their quality
in the meantime.


I have one request though. You are sometimes asking people to close
the PRs because you don't want unfinished PRs in the queue. I would
like to suggest adding a special label to such PRs before closing
them, saying something like "workneeded". I would occasionally like to
be able to search for such contributions. These are contributions that
are basically welcome / needed / acceptable, they only need a bit more
expertise or just some simple touch before they could be merged. I
would like to distinguish contributions that are closed because they
are wrong / obsolete / replaced by another PR, from those that have
been closed just because the work was not 100% complete, and if
someone has time to look at them, they could be fixed and merged.

Mojca

PS: My painful record was waiting for 6 years for upstream to include
2000 lines of code (because, you know, compiling their source even on
windows was "trivial", not to mention that it depended on Qt,
wxWidgets, freetype, gd, libpng, libjpeg and everything else that
comes with it; while downloading a binary of another piece of software
that would allow testing them the code was deemed above the threshold,
so they wanted to wait until that software made it into debian
stable). By the time it got included I basically lost interest in
working on it any further.


More information about the macports-dev mailing list