Date: Sat, 16 Sep 2000 20:30:50 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: I'll be rolling a 4.1.1 release on September 25th Message-ID: <Pine.BSF.4.21.0009161958320.86933-100000@freefall.freebsd.org> In-Reply-To: <v04210101b5e9c96fb10c@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Sep 2000, Garance A Drosihn wrote:
> >Poeple often pop up right before a release is due to be rolled, and
> >ask for some patch to "make it into the release" - often it doesn't,
> >and they go away until the next release is announced. This isn't how
> >the FreeBSD development model works, and you're targetting the wrong
> >group at the wrong time. You need to get your patch applied to
> > *FreeBSD-CURRENT* preferably a month or more before the release, and
> >then get it merged back to -stable.
>
> You left out the exact steps on how someone who does not have
> commit privs is supposed to "get their patch applied". I, for
> one, have found that process frustrating. Someone writes a PR,
> including a patch, and often the PR just sits there. It is up
> to the same person to find some committer, and pursue that
> person until they have time to apply the update. The most
> obvious person for a given piece may be swamped at the time, at
> which point the patch-writer has to go around hounding other
> people. Those other people, in turn, will feel uncomfortable
> because they're not familiar with that area of code -- and besides,
> they're already busy with other code that they already know. The
> patch-writer tries writing messages to public mailing lists. They
> try to be polite. They try do stir up some interest. They hope
> that someone somewhere will pick up the patch and apply it.
This is a fairly accurate assessment of the usual way this goes.
Unfortunately the existing FreeBSD committers as a group don't seem to do
much work with code submitted via PRs, except for PRs which fall within a
specific person's area of responsibility (at least, this is my impression)
- in other words, we don't have many people who take care of all of the
"miscellaneous" PRs. I fully understand it makes it annoying and
frustrating for submitters, but I don't know what the solution for
non-committers is except for cornering and working closely with an
individual committer and making them promise to take care of it - if you
just submit and forget, it's not likely to have swift results.
The problem is that when we get a new committer, they invariably become
tied to a particular area of the tree after some length of time which
takes up all of their attention, and the net result is that PRs which are
in areas where no committers have their attention focussed have noone to
champion them.
> After spending ten times more effort trying to get someone to
> apply the patch than was originally spent MAKING the patch,
> they give up.
Yes :-(
FreeBSD always needs more committers. Traditionally the way you get
committer status is to work with an existing committer in some area of the
system, and once they've seen you've "got what it takes" (i.e. ability to
work with the impact of changes on an OS-wide level) they'll be able to
sponsor you to -core and be able to stand up for your competence.
> A release is announced. They get a bit excited, and hope once
> again to get someone interested. They are then told that they
> are "not following the FreeBSD development model". As near as
> I can tell, the "freebsd development model" is that either you
> yourself are a committer, or that you pray to the deity of your
> choice that a miracle happens.
Well, it's a simple fact that patches don't get freshly applied to -stable
without maturation in -current. Given that it can be difficult to get
minor changes applied, then following this path and sending mail to a
non-developer group at release time is a misdirection of effort.
> Given that it is clear that writing a PR is insufficient to
> getting a patch applied to current, I suggest that the reply
> to any PR which includes a patch should also detail what the
> remaining steps are. Who *is* someone supposed to bug? What
> *are* they supposed to do when the "obvious someone" honestly
> is too busy to look at their PR? If this is "the wrong group"
> at "the wrong time", then what is the RIGHT group, and at
> exactly WHAT time will that group not be frantically busy with
> other work to do?
The appropriate "development" mailing list, either -current, -net, -alpha,
etc. The time is any time, although away from the release cycle there are
more committers who aren't tied up doing release work so chances are
higher.
> So, let me add a disclaimer here. I realize the committers are
> busy. Fine. But don't just dismiss someone who sent in the PR
> as if they weren't following some obvious set of rules, and
> thus it is their own fault that it takes years to get a reply
> to a PR. The PR's aren't answered because there's still more
> work to do than there are people to do it. Period.
It wasn't intended to be dismissive - but since this is something which I
see repeated around the time of most releases I wanted to point out to
people why it doesn't work.
> Do not kid yourself, and insult the rest of us, by claiming that
> if we just wrote one more message to "the right place", then PR's
> which include patches might actually be looked at. If someone
> is not a committer, then they have no real way to "force" any
> patch to be applied. So, do not blame *them* when PR's are left
> to languish in the PR database.
If my message came across as carrying blame, then I apologise - this was
not the intent.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009161958320.86933-100000>