How are [MAINTAINER] patches handled and why aren't PRs FIFO?
jerry at seibercom.net
Wed Apr 27 13:33:02 UTC 2011
On Wed, 27 Apr 2011 08:50:52 -0400
Robert Huff <roberthuff at rcn.com> articulated:
> Jerry writes:
> > > Ha, i've submitted mine about two months ago and still no luck.
> > Personally, I believe that the current system, if not partially
> > broken, is far from ideal. 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.
> Not all committers are created equal. Asking Joe-the-fonts-
> guru to work on Mary's network monitoring application is probably
> not productive.
> Keeping a centralized list of who/what pairs - more
> importantly, keeping it useful - is another job on someone's desk.
> Are you that someone?
> > I am sure that the old, "But they are all volunteers", or some
> > such tirade will erupt.
> Not a tirade, but ... guilty.
> > It must be remembered that those who submit items for approval
> > are also volunteers. They deserve at least as much respect as
> > those who are actively working on those submitted items.
> Am I correct you are asking for a (far) higher level of
> dedication from the committers than from those who submit changes?
> Consider the port that goes untouched (in spite of substantial
> upstream changes) for months or even years; someone picks up the
> torch, and the poor committer gets N-thousend lines of new features,
> security patches, and dependency changes dumped on them to be
> checked in ... how long was that?
> Do I think there are flaws in the current system? Sure.
> But as long as we're faced with this particular choice of
> - slow updating versus lowered quality - I vote "first, do no harm".
I am not sure how the Hippocratic Oath got involved here. In any case, I
see no reason why the "slow" and "lowered" qualities cannot find
Please reread what I posted. I stated that if a submitter's item was to
be delayed for an extended period or bypassed in favor of a later
submission by another submitter then the submitter of the older item
should be notified as to why and if possible given an approximate
commit date. I fail to see why that would cause undo stress or an
unbearable burden on the committer(s). The committer(s) could create a
boiler plate document to handle just such cases.
However, I do find troubling you statement regarding a large update to
an older port or even a new port submission for that matter. I see no
logical reason for a committer to bypass an item simple based on its
size or the amount of work involved in getting it committed. After all,
consider that the original submitter invested a large amount of his/her
time in that same item.
The only honest and fair way to handle ports request is on a FIFO basis
unless a bona fied excuse can be shown to deviate from that procedure.
To simplify the system, a two week limit, or whatever reasonable time
frame can be agreed upon, should be put into effect. Any submitted item
that cannot be committed within that time frame would require the
committer to notify the submitter of such and if possible a reasonable
date to complete the commit. I do not believe that, that is by any
stretch of the imagination excessive. Many government and private
organizations work under those same basic constraints without undo harm.
jerry+ports at seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
The great nations have always acted like gangsters and the small nations
More information about the freebsd-ports