Merging pull requests before 72 hours

[Mojca Miklavec]

Hi,

I would find it useful if we try to "rewrite" rules about how
maintainership is supposed to work, to make them less ambiguous and to
reflect how the majority of us would like to see it working in the
future. (We do need to take differences between the old svn and the
new github workflow into account.)

Below are some of my thoughts about (not) dropping maintainers:

On Thu, 18 Oct 2018 at 22:38, Christopher Jones wrote:
> > On 18 Oct 2018, at 9:25 pm, Ken Cunningham wrote:
> > On 2018-10-18, at 1:18 PM, Christopher Jones wrote:
> >>
> >> Beyond the above, not really. If it is indeed agreed that some package version updates are allowed under the ‘minor’ tag, then I think the best you can do is just state that, and acknowledge that the determination of what is or is not a minor package revision cannot be quantified in generality, so is up to the member to decide making the changes, and that disagreements are inevitable.
> >>
> >> Or, we decide no package version updates are allowed.
> >>
> >> Chris
> >
> >
> > Has MacPorts considered removing the whole "maintainer" idea (with the possible exception of a very few key ports that are presently not openmaintainer)?
> >
> > It seems to cause a fair bit of frustration, delay, and confusion and I'm not certain it offers a whole lot of benefit.
> >
> > Homebrew has no such concept.
>
> I am not at all familiar with Homebrew. How do they work, does everything go via a PR with them ?

There are a bunch of differences between MacPorts and HomeBrew.

For example, they have one crazy contributor with nearly 19k commits
(according to openhub) in the last 12 months alone (ten times more
than any one of our committers and nearly the same as Ryan's total
count since the beginning of the project). One would think that's an
AI bot :) :) :)

Some time ago they kicked out most of the formulas and only kept those
deemed important enough (and backed by high number of installations as
indicated by collected statistics).

Don't take the next piece of information for granted (I believe I
heard it in one of the talks of the founder, but I'm not absolutely
sure). I seem to remember that at some point in history they were the
number one most active project on the entire GitHub universe.

They currently have 28 issues open for formulas. We have ...
thousands? (Last time I checked it was somewhere between 4k and 5k.)
Disclaimer: I don't know what their policy on closing the issues is.
Apple for example would not do a damn thing when you report a bug, and
then it will automatically close it after X days for the lack of
activity, even if the bug is still present.

Yes, with pull requests and a very small number of super active and
highly skilled people checking them it's not such a problem if there's
no definite maintainer assigned.

But on the contrary, Debian would remove any package which doesn't
have a maintainer assigned.

What I see in MacPorts is that, with the exception of a small number
of critical ports (where breaking it would cause serious issues to
lots of users), in most ports having the maintainer assigned is more
of a responsibility and commitment to try to fix the reported issues
(and communicate with upstream, to both report bugs and submit
patches). I also often run "port livecheck maintainer:myusername" to
see which ports I need to look into. If we remove the port maintainers
completely, I will neither notice the bug reports nor know that I
should have updated a port. (I would see those if we ever get back to
having 100 tickets open as opposed to 5k.)

I already suggested some years ago (and I still believe we should one
day implement this) is to establish some kind of "groups" where people
could "subscribe to". Then any bug report for gnuplot would be CC-ed
to gnuplot at ports.macports.org rather than myself. And anyone
interested in that port could subscribe and:
- receive bug reports
- receive notifications of new pull requests for that port
- receive notifications of failed builds on the buildbot
- easily check whether the port (that is: any of the ports the user is
"subscribed" to) has been outdated
Some ports could be merged together, for example "crossgcc" could be a
group for all gcc cross compilers, p5 could be a group for all perl
modules, ...

There are a bunch of ports which I don't maintain, but I would be
interested in watching over. Some of them already have a maintainer.
Some don't, but I cannot commit to maintaining hundreds of ports.
Having the machinery to subscribe to arbitrary ones would probably
sometimes help.

And yes, we have a huge number of people assigned as maintainers who
no longer maintain the ports. We really need to clean up the list in
order to reflect the reality.

Mojca