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

Jerry jerry at
Wed Apr 27 13:45:51 UTC 2011

On Wed, 27 Apr 2011 09:17:46 -0400
Steven Kreuzer <skreuzer at> articulated:

> > 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
> started.
> > 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
> production?
> 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.

Thank you. A well thought out reply and one that I can agree with in
most aspects. I think that 'UPDATING' the PR to let the submitter know
that he/she has not been forgotten and to keep them aware of any
problems with the PR is certainly a welcome suggestion. Unfortunately,
that is rarely presently done. Certainly, we should all be able to come
to some consensus as to what constitutes a reasonable time frame.

Jerry ✌
jerry+ports at

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

More information about the freebsd-ports mailing list