Date: Thu, 19 May 2016 08:43:11 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: "K. Macy" <kmacy@freebsd.org> Cc: Randy Westlund <rwestlun@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: What changes are welcome? Message-ID: <606685411.106534014.1463661791680.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <CAHM0Q_PYx%2BTckMXZtPmiNtELxBnftPUzVxYS1kK3b1aNe3XVWg@mail.gmail.com> References: <20160519041118.GE19887@gmail.com> <CAHM0Q_PYx%2BTckMXZtPmiNtELxBnftPUzVxYS1kK3b1aNe3XVWg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
K. Macy wrote:
> On Wed, May 18, 2016 at 9:11 PM, Randy Westlund <rwestlun@gmail.com> wrote:
> > I'd like to start contributing to the base system, but I need
> > clarification on what sort of changes would be welcome.
> >
> > I thought I'd start on simple compiler warnings. The top code in
> > /contrib/top, for example uses K&R-style function definitions and
> > implicit return types that spews -Wimplicit-int and -Wreturn-type
> > warnings.
> >
> > While I'm silencing those, is it appropriate for me to make the file
> > follow style(9)?
> >
Also, please note the following paragraph in style(9):
In general code can be consider "new code" when it makes up about 50%
or more of the file(s) involved. This is enough to break precedents in
the existing code and use the current style(9)guidelines.
Given this, I (others will disagree;-) wouldn't make style(9) changes that
aren't required to fix the code unless you are re-writing a large part of
the code.
I'll also note that /contrib may not be a good place to start, since I think
(not sure about userland) code in there is often taken from some upstream
location and any changes done locally must be merged with upstream stuff
each time it is updated. (I have no idea if /contrib/top is actually handled
this way.)
And, yes, as K. Macy noted, committers are pretty well all volunteers who
work in certain areas of the code, so changes to some part of it they don't
work in will probably be ignored unless it fixes something important.
(For example, no one has recently been working on fuse. Since I am now using
it, I have been coming up with some patches. I have not yet found anyone
willing to review them, so I've been committing them without review.
This is allowed in FreeBSD, but since fuse isn't my area of expertise,
reviews would have been nice.)
Most people start working on ports and become committers there and then
src committers later. Btw, if you are interested in doing testing and
review of fuse changes, you could email me.
rick
> > Once I have a diff, should I just upload it to bugzilla, or is it
> > preferable to put it on phabricator and then link to it from bugzilla?
>
> Phabricator is the place to put any patches you want reviewed.
>
>
> Just as important to understand as the technical is the social aspect.
> FreeBSD does not have a 6c equivalent to the Linux Foundation or large
> companies like Redhat where individuals are paid full-time to
> facilitate the import of contributions. You need to go out of your way
> to cultivate a rapport with one or more committers so that one of them
> will take time out of his day to commit your changes and potentially
> cope with any fallout. I contributed some changes a day or two ago and
> I broke the kernel build in a couple of arches :(. You're going to
> find that without such a rapport in place your patches are likely to
> be ignored or, if they're substantial, worse yet actually argued
> against.
>
> And if at first you're ignored, don't take it personally. FreeBSD is a
> collection of individuals, each with his or her own hot buttons and
> interests.
>
> -M
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?606685411.106534014.1463661791680.JavaMail.zimbra>