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
