Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Ryan Schmidt wrote:
>>> After all, MacPorts maintainers are just some people devoting their
>>> free
>>> time to writing Portfiles. Sometimes other stuff in life stops them from
>>> responding to tickets or addressing certain issues.
>>
>> This is a given. Open source projects are mostly staffed by unpaid
>> volunteers. I don't feel entitled to recieve updates, as it's all free.
>> However, a well-run project does inspire constant commitment to keep it
>> running smoothly. MacPorts does not *feel* like being very active, quite
>> inaccessible to new users and there does not appear to be current
>> information easily accessible. A good example for this would be the move
>> to GitHub. Some status messages outside of the mailing list or even a
>> dedicated FAQ would go a long way. Without this mailing list, an
>> outsider easily gets the impression MacPorts is outdated and running on
>> fumes.
>
>What gives the impression that we aren't active?
>
>There are tons of posts on the mailing lists every week.
>
>There are tons of commits to the repository each day.
>
>There are tons of tickets filed each week.

Before I was subscribed to this mailing list (something I haven't used
for ages), there was no easy way to see anything going on. Before I
installed MacPorts a couple of months ago, I was seriously surprised to
see an installer for El Capitan at all. I could have sworn MacPorts was
outdated and development had stalled. It took days of patient perusing
the documentation until it clicked and I got why MacPort is the way it
is.

I believe the impression of staleness mainly comes down to:

- The very old school website structure (not at all intuitive, lots of
  clicking around and text searching necessary). I don't mean flashy
  design, I mean readable, easy to understand instructions that are
  grouped and interlinked smoothly.
- The current Trac being kind of unwieldy
- Me being used to working with Git and GitHub/BitBucket/GitLab
- The manual diffing process

In essence, practically everything about MacPorts feels "old" and
utilitarian, leaving a taste of staleness.

I believe it may be difficult for a project "insider" to view things
from the perspective of an "outsider". Younger developers (which does
not include me), especially not those working on kernel code or
industrial automation systems, are used to issue tickets like GitHub,
not older Trac versions. To web-based discussion or Slack channels, not
mailing lists. To Git, not SVN. They use GUI editors, not Vim. They code
in Node.js, not C.

The point being: MacPorts feels dated, a bit exclusive and very "dry"
when in reality it is none of those things. Attracting new contributors
has a lot to do with how a project comes across.

>>> I can understand your frustration about broken ports and missing
>>> updates. I have that as well.
>>>
>>> If your work depends on these ports, you benefit from the donation of
>>> time from the people keeping the port up-to-date. The best you can do if
>>> you encounter a problem is to check if it is a known issue in our Trac.
>>> Sometimes others already proposed a solution but did not have the time
>>> to get through with updating the Portfile in multiple iterations testing
>>> the change. Yes, this is a time-consuming process, but others would
>>> benefit from your work as well as you benefit form theirs.
>>
>> Absolutely. The process itself of posting a diff just feels archaic and
>> like an uphill battle.
>
>And we will switch to GitHub, and use pull requests. But sending a pull request, or attaching a diff to a ticket, is not the hard part.

True, but it will make the "business part" of submitting the patch more
straight-forward.

>>> Even as a non-committer you can easily work from a Subversion
>>> checkout
>>> with local modifications and create the patch from there. Or you keep a
>>> separate local ports tree that you diff against.
>>
>> I actually keep a local ports tree with modifications for a couple of
>> ports that are not updated in a timely manner. Given a smoother
>> workflow, I'm very interested in updating those for the benefit of all
>> users. My experience so far is that things move very slow if at all.
>
>If a ticket does not move in 72 hours, write a note to this mailing list requesting someone look at it.

I'll be sure to remember that.

>But in either case, the hard part is "make the edits, test them"; that
>doesn't change when we move to GitHub. We current receive many
>low-quality submissions that require further editing. I don't
>anticipate the quality of submissions will magically improve just by
>moving to GitHub.

By itself it will probably not. But the submission process will be
easier for contributors and the pointing out of problems will be
clearer.

>Something we could do to improve the quality of submissions would be to improve the quality of our portfile-writing documentation. Someday I would like to rewrite all of our documentation in a new cohesive format, but that is a big effort.

If you need help with that, let me know.

>> If changes are needed, they can be coordinated on a line-by-line
>> basis directly within the pull request until everything is in order.
>
>I will admit that this process is completely foreign to me. We will all have to learn how to work with GitHub once we switch.

Once you have worked with it for a while it becomes incredibly useful
and you will not want to go back.

>> Optionally, an automatic build process can be triggered with any
>> single
>> commit so that immediate feedback about the state of the commit can be
>> viewed directly from within said pull request.
>>
>> Obviously, the feasibility of automatic builds relies heavily of the
>> available infrastructure. With hundreds of commits per day this could
>> make automatic build very slow. However, a service like Travis offers
>> free CI infrastructure for open source projects and provides several Mac
>> OS X/macOS environments.
>
>Travis is not appropriate for us. (For one thing, Travis doesn't give root access, which MacPorts needs.) Therefore we have our own Buildbot system:
>
>https://build.macports.org
>
>But we cannot use the existing system for untested pull requests; among other problems, that's a security risk. We will need to develop a new system for that, likely involving spinning up new pristine virtual machines for each build attempt and destroying them afterward. I imagine this will take a long time to develop and I don't see this happening anytime soon.

I see.

>> This may explain why things feel like they are moving very slowly.
>> With
>> major changes behind the scenes it is quite understandable that an
>> already limited supply of time is stretched even thinner. This is also a
>> perfect example of why better communication would go a long way. A
>> prominent note on the website with further information about the current
>> state of the project, the switch to GitHub and insight into why things
>> are the way they are would keep everyone in the loop.
>>
>> If you think, like me, that this kind of information would benefit
>> users, I'll gladly volunteer to keep those entries current, freeing
>> resources for the core developers and infrastructure engineers.
>
>We announce things on the announcement list and on the news section of our web site as it happens. I don't have any further status updates that I wish to communicate at this time. I don't know what kind of prominent note you would like to see on the web site. A note that we are still alive?
>
>I recognize that our web presence is not up to modern standards. I indent to modernize it, after we move to GitHub.

I believe a lot of the points I addressed above will disappear once
MacPorts is a GitHub project. The notice I was referring to would
contain information about why things may appear to be moving more slowly
than usual and a FAQ regarding the move to GitHub. I for one would have
found that very interesting and enlightening. If you prefer to be
exclusive to this mailing list, that is your prerogrative but certainly
wouldn't help with attracting new contributors.