How are [MAINTAINER] patches handled and why aren't PRs FIFO?

Steven Kreuzer skreuzer at
Wed Apr 27 13:17:47 UTC 2011

> Personally, I believe that the current system, if not partially broken,
> is far from ideal.

Speaking as a ports committer, I do agree with you that the current workflow
that we have in place is less then ideal for the size of the ports tree as well
as the number of patches that we receive.

When the current workflow was first developed, the ports tree was much
smaller and
easier to work with. It has grown to over 23,000 ports and we are starting to
see scaling issues.

However, these issues have been known for quite some time. Behind the scenes,
numerous ideas have been kicked around on how to better deal with
contributions from
independent developers, how to accept and review patches quicker and
how to generally
streamline our workflow.

Unfortunately, the problem really becomes that unless we want to
severely disrupt what
we currently have in place for an extended period of time, we can
really only make small
gradual changes and hope that eventually we end up in a better
position then when we

> I would prefer to see a system where each submitted
> PR is assigned a specific number (I believe it is actually) and then
> assigned in numeric order to the next available committer. That
> committer would then be responsible for either committing the
> PR/Port/Whatever within a preset time frame, or informing the original
> submitter why the said article was not/could not be approved at the
> present time. Allowing a submitter to languish while pondering what has
> become of their document certainly does seem justified.

The problem with this system is that certain developers sometimes only
work on a certain
subset of the tree. Your fifo system does not take that into account

For example, I maintain quite a few perl modules and often
grab PRs for perl related things. This is mainly because I have an
interest in keeping
the perl stuff in good shape because I use it every day. I generally
never deal with
any PR that deals with ruby since I don't use ruby. As a result, I am
not familiar with
the ruby specific knobs in the ports tree. I would rather let another
developer who is
familiar with those and has an interest in keeping ruby well
maintained deal with those
PRs. Unfortunately, from time to time, the person who deals with the
ruby stuff could be
swamped with work or family issues and is unable to attend to it as
quickly as I may have
been able to. Would you prefer to wait a little while longer for that
person to grab the PR, or
would you rather have me commit the patch and possibly break your
application running in

Also, with your fifo system, what would happen if I don't commit an
update within the allotted
time frame?

Perhaps the happy medium is that if you submit a PR and it doesn't get
assigned for a few days,
maybe ask in #bsdports on irc if someone could take a look at the PR.
If you submit a patch
and it does get assigned but a few days goes by and it doesn't get
committed, we could update the
PR to let you know that we haven't had a chance to look at it but hope
to have a little bit of time in
the next few days to take care of it.

More information about the freebsd-ports mailing list