Re: Backporting DFly patches to FreeBSD?

[Max Okumoto <okumoto@xxxxxxxx>]

Garance A Drosihn wrote:
> At 6:07 PM -0800 2/17/05, walt wrote:
>
> > DFly has an important improvement to /boot/loader which really
> > should be applied to the FreeBSD source tree.  I have no
> > credibility with the FBSD project, but some of you folks do.
> >
> > Is there someone here who could lobby the FBSD developers to
> > apply our patch to their sources?
>
>
> Well, there are some freebsd committers on this list, and at least
> part of the reason we are here is take notice of good ideas that
> we should be stealing...   :-)
>
> But it depends on what change you're interested in.  Some of the
> changes are just hard to "side-port" into FreeBSD, just because
> so much has changed between FreeBSD 4.x and FreeBSD 5.x and 6.x.
>
> There are several things that Matt has done that I would very much
> like to get into FreeBSD, but I'm already busy due to various
> FreeBSD-related side-projects of my own.  The amount of free time
> that I have will not increase due to your lobbying, so "lobbying"
> per se simply annoys me.  If you want to lobby people, then go into
> politics.  I am quite interested in things in Dragonfly (and OpenBSD,
> and NetBSD, and Darwin...), but I still just work on what I want to
> work on, not what someone else tells that that I "should" work on...

Its really not about lobbying.  If you think that something is of
intrest to FreeBSD then submit patches to them.  Be polite, and start
by giving reasonable sized patches with a description of what it does.
And if possible split them into steps. (Evolve the code)  Unless the
person looking at the patch really knows the code, an major changes
can appear as magic.  And keep track of what you submit.  People make
mistacks, and sometimes missapply patches.

People usually don't reject patches for features because its from
dragonfly bsd.  Its more a matter of time, and trusting that the person
submitting a patch knows what they are doing.  As Garance says, people
have thier own projcts.  So anything that reduces their effort helps.

The advantage is that other people see and use your code.  A good
set of patchs requires just as much effort, and in many cases more
that writing the code itself.  Both projects win since there is more
eyes looking at the code.  It feels great when you know that something 
is better because of you.

					Max