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_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
