A potential new porter seeking some clarifications

Kubilay Kocak koobs at FreeBSD.org
Fri Dec 14 08:09:11 UTC 2018


On 14/12/2018 2:11 am, Lars Engels wrote:
> On Thu, Dec 13, 2018 at 10:41:01PM +0800, Arthur Pirika wrote:
>> Hi all! I’m hoping to get into porting for FreeBSD, right now just
>> focusing on one package, a plugin for bitlbee, however I’d like to
>> extend my hand to maintain other ports in the future once I have more
>> knowledge and practice with the system.
> 
> Welcome! :-)
>>
>> Before I start, though, I just need some clarifications of things from the porter’s handbook.
>>
>> 1. If I understand correctly, the version of the ports tree as fetched
>> by portsnap isn’t the best for working on the tree. I should instead
>> make another copy of the tree as an svn checkout? Distfiles, however,
>> still go to /usr/ports/distfiles
> 
> You can change this by setting DISTDIR variable in /etc/make.conf to a
> directory you like. See ports(7) manpage.
> 
>> 2. Is it absolutely necessary to use poudriere before submitting a
>> port? I’m still getting to grips with how it works, and if I need to
>> get comfortable with it first, I’ll do so.
> 
> That really depends on the change's size. Trivial patches can often be
> sub-/committed without a poudriere run. portlint -ac, make check-plist
> and make package can find potential issues for you.
> Bigger changes should be build in poudriere. You don't need to attach
> the logs to the PR, though.

tldr: It is absolutely necessary if we don't want to shuffle 'quality' 
work to "someone else" as a project/culture/community, we want to pick 
up issues as early as possible and if we want our contributions as 
committers and not-yet-committers alike to be taken seriously, hopefully 
resulting in quicker times to commit in the latter case.

The degree of QA required, putting it gently, is not at all contingent 
on, or proportional to *change* size or "apparent" simplicity. That 
contention needs to go away.

Note: Lars, I'm certainly not pointing the finger at you here, or anyone 
else in particular.

The canonical example historically used, and sometimes (too often) 
described as 'simple' by both committers and contributors, mostly only 
ever used to imply that QA (or more of it) isn't necessary to get a 
Bugzilla issue assigned/closed more quickly, is the "minor PORTVERSION 
bump and a distinfo update".

In the meantime along with that two line "simple" patch, upstream has 
added/removed dependencies, added or removed a few files (pkg-plist), or 
at worst, broken/regressed something entirely, to name only a few cases.

While special targets (check-plist) can be and are useful, the only form 
of QA we should be doing is 'all of it', and at the present moment, that is:

  1) portlint -AC (or better)
  2) poudriere testport (supported versions/archs, at least tier1 [1])
  3) make test for run-time QA [2]

Even (1) and (2) alone, while being the making up the bulk of our QA, 
which is notable not 'everything, everytime', is insufficient, as it 
mostly picks up only 'our' errors, not the softwares issues, which 
ultimately impact users.

[1] non tier1 is not as trivial as it should be to setup in poudriere.
[2] if test suites exist, TEST_DEPENDS and test: target should be hooked up

./koobs


More information about the freebsd-ports mailing list