Bug 221211

Summary: How to improve new port submissions
Product: Services Reporter: Yuri Victorovich <yuri>
Component: Bug TrackerAssignee: Bugmeister <bugmeister>
Status: Closed Works As Intended    
Severity: Affects Only Me CC: adamw, grahamperrin, koobs, portmgr
Priority: --- Keywords: feature
Version: unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
all-unique-portlint-FATAL-errors.txt none

Description Yuri Victorovich freebsd_committer freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 2017-08-04 18:35:46 UTC 
Created attachment 185026 [details]
all-unique-portlint-FATAL-errors.txt
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2024-01-14 06:05:19 UTC 
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.