What is the problem with ports PR reaction delays?

John Marino freebsd.contact at marino.st
Sat Jan 25 07:46:12 UTC 2014

On 1/25/2014 05:16, Alfred Perlstein wrote:
>> Thus, are you volunteering for this role?  It's not my call, but if you
>> really want to do clean out and triage the all PRs on an ongoing basis,
>> my guess is that would be very welcome and we'd figure out a way to set
>> that up.  It would definitely help, especially for those maintainer that
>> "approve" patches but the PRs never get opened (or set to a better state
>> than "open").
>> At some point we'll have a new PR system, that fact might be having an
>> impact on current PRs as well...
> To me it would speak of tooling as opposed to anything.
> Does the ports system have a 1 or 2 click interface for merging PRs like
> for instance github?

The SCM part of the ports process is not the bottleneck.

> Could ports take PRs in the form of pull requests on github? 
> Wouldn't that just turn the number of updates into a few minor clicks?

This makes a fatal and untrue assumption: That was is submitted just
needs to be committed.  In my brief experience, I can tell you that's
simply not true.  If a submission can be taken without a single change,
that is truly an exception.  It's not even the submitters fault often,
sometimes the infrastructure changes but the submitter didn't know or
account for it, or the PR came before the infrastructure change.

One can RARELY take a submission as-is.  Thus, pull requests turn into
merge conflict exercises and cause more work, not less IMO.

> (also wouldn't it make it easier for ports submitters)?

personally I don't really think so, plus I don't see the current or
future PR system as the barrier for port submitters.

> (maybe there is some great ports system that I'm not aware of that makes
> this all as easy github, but I somehow doubt that.)

I would like to see something where the submission gets tested in
Redports automatically, and automatically annotates if the port passes
on all platforms or not.  Then the submitter gets notice it needs fixing
immediately and FreeBSD folks don't have to take the PR, test it, reject
it, and state why.  That iteration can take a few cycles and automated
testing could cut that process time tremendously.


More information about the freebsd-ports mailing list