There is a backlog of new ports of ~250. My suggestion how to improve the situation in the future: 1. In bugzilla, add the checkbox "Is this a new port?" 2. If the answer is "yes", ask "Does this port pass stage-qa test?", "Does this port pass 'porlint -A' test?", "Does this port build in poudriere?". 3. If any answers are "No", bugzilla shouldn't accept the new port. 4. Add URLs with explanations what are stage-qa, portlint, poudriere, and how to use them. 5. If this is a new port, add prefix [NEW PORT] to the subject 6. Strictly limit new submissions to shar files created from /usr/ports. There is no benefit in allowing patches, or shars created from other directories. This only adds work for reviewers to guess what command to run to extract it. 7. Add a script checking that submitted file is a shar, and that it only creates the right files, and under one of the existing categories, and no such port directory exists. Reject, if any of the conditions aren't met. 8. 'portlint -A' can even be easily run from bugzilla. This can dramatically improve the quality of submissions. I checked few new ports in the queue, and each one had some obvious problems, and didn't pass some of the tests. All these suggestions will make problems be caught on the level of bugzilla. New ports will be much more likely to be committable.
The PH says both patch and shar are acceptable, and I very, very strongly prefer patches. Machines with write access to the FreeBSD svn repo shouldn't be running shell scripts from untrusted sources.
(In reply to Adam Weinberger from comment #1) All such operations are supposed to be performed in jail. Untrusted patches can also overwrite other important files.
Either way, we accept patches. I like the rest of your proposal, but not the shar-only part. Does BZ support the process you're proposing?
BZ is in perl, so it is easily modifiable. This bugzilla has obviously been modified, that's how it auto-assigns bugs, notifies maintainers.
I strongly disagree with 6, we prefer patches, shar is slowly being phased out. 7 is then out. I also disagree with 8. First because portlint, being a static lint tool, says a lot of bad things, that you have to sift through and ignore. And second because you have to apply the patch, which means you need to figure out a magic way to discover where it should be applied.
7. can be done with patches as well. > you need to figure out a magic way to discover where it should be applied. 'svn diff {category/port-name}' always creates patches of the same format. There is no magic required.
(In reply to Mathieu Arnold from comment #5) > I also disagree with 8 (suggestion to run portlint). First because portlint, being a static lint tool, says a lot of bad things, that you have to sift through and ignore. Actually, portlint only prints lines labeled with WARN or FATAL. I just ran portlint on every port in audio/, and every FATAL error seems reasonable, and should ideally be fixed. Please see the log as attachment. WARN messages can be ignored, or suggested to the user.
Created attachment 185026 [details] all-unique-portlint-FATAL-errors.txt
While it's true we need to streamline our "new port" submission, IMHO these are too restrictive. I think it's fair to ask if it passes portlint, and a 'make describe' from the <category>/Makefile. But beyond that I consider this more a social problem than a technical one.