Improving the handling of PR:s
igor at hybrid-lab.co.uk
Sat Jan 12 07:42:51 PST 2008
On 12/01/2008, Kostik Belousov <kostikbel at gmail.com> wrote:
> I taken the patch, because I though that
> I have such card. After the truth revealed that I am not, I preferred to
> not broke support for somebody hardware. If there are other users of the
> same card, why do not they complain and test the patch ?
This is fairly generic and doesn't necessarily just apply to your
post, but here you expect the users to be *developers*; and while most
people would happily try something pre-compiled, or at least merged
into the source tree (so they can just do a make xxx), significantly
fewer people would be wanting to experiment patching. Firstly you
expect the users, most of whom are just trying the OS out, to dig
through the PR database, then to patch the necessary files, configure
their system (once they figure out how to edit the relevant KERNCONF
file), and so on...
Seriously, what's wrong with merging various patches into the source
tree and surrounding them with #ifdef WITH_EXPERIMENTAL_CODE, or
WITH_EXPERIMENTAL_(module name) and then allowing that in make.conf?
At least that'll take the hassle of searching through PRs/mering...
Alternative (for more advanced hackers) would be to have a dedicated
page that lists various experimental patches categorized by
module/subsystem/etc, which allows people to pull the experimental
Another alternative is to have a boolean flag on the PR so that the
author can indicate that it's a patch and have the gnats mail a
separate list of uncommitted patches separately to other open PRs?
More information about the freebsd-current