Issues with oudated ports / GitHub

Ken Cunningham Webuse ken.cunningham.webuse at gmail.com
Fri Oct 7 12:24:16 PDT 2016


On 2016-10-07, at 10:05 AM, Rainer Müller wrote:

> I am not sure how we could change these to make triaging trickets easier.

I can't easily just look at the list and see what are new requests for ports to be included in macports. It all mixed in with other things.

Also, the committer time needs to be more protected to keep things moving more quickly. The fairly small group of committers with the deep MacPorts knowledge and experience frankly doesn't have time to do the mass of grunt work. They should be mostly reviewing and commenting on other's work, sending things back for needed fixes, rather than writing much themselves. And there might need to be a distinction between style critique and actual function failures, as things do have to move along.

Like Ryan said, I'd have separate queues for each major category..let's see -- 

	new incoming port requests that anyone could claim - port that don't exist in macports at present

	new portfiles that have been finished and are awaiting committer review

	requests for updates to existing ports by people who have noticed something out on the web of significance. 

	port updates with patches (approved by maintainer if there is one) waiting for committer review


> Requests for new ports could still be valid after years. This list could
> be helpful for newcomers that want to create new ports. 

Totally agree - but I'd close everything over six months old or something like that for optics. People can still search to "closed" tickets if they want.

I'm still thinking of resurrecting the hylafax portfile from 8 or so years ago. And I did just use the webmin portfile from about the same vintage two weeks ago :>


Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20161007/3abc5843/attachment.html>


More information about the macports-dev mailing list