Bug 221211 - [suggestion] How to improve new port submissions
Summary: [suggestion] How to improve new port submissions
Status: New
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Bugmeister
Depends on:
Reported: 2017-08-03 23:19 UTC by Yuri Victorovich
Modified: 2017-08-04 18:35 UTC (History)
3 users (show)

See Also:

all-unique-portlint-FATAL-errors.txt (3.09 KB, text/plain)
2017-08-04 18:35 UTC, Yuri Victorovich
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2017-08-03 23:19:14 UTC
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.
Comment 1 Adam Weinberger freebsd_committer 2017-08-04 00:26:15 UTC
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.
Comment 2 Yuri Victorovich freebsd_committer 2017-08-04 00:31:40 UTC
(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.
Comment 3 Adam Weinberger freebsd_committer 2017-08-04 00:48:16 UTC
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?
Comment 4 Yuri Victorovich freebsd_committer 2017-08-04 00:55:22 UTC
BZ is in perl, so it is easily modifiable. This bugzilla has obviously been modified, that's how it auto-assigns bugs, notifies maintainers.
Comment 5 Mathieu Arnold freebsd_committer 2017-08-04 09:05:37 UTC
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.
Comment 6 Yuri Victorovich freebsd_committer 2017-08-04 09:31:18 UTC
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.
Comment 7 Yuri Victorovich freebsd_committer 2017-08-04 18:35:25 UTC
(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.
Comment 8 Yuri Victorovich freebsd_committer 2017-08-04 18:35:46 UTC
Created attachment 185026 [details]