Re: musl setup attempt

[LM <lmemsm@gmail.com>]

On 3/15/13, Isaac Dunham <idunham@lavabit.com> wrote:
> A few points:
> 1) Patches beat bug reports.  Make sure that you note upstream policy about
> copyright assignments and so on, though.
> Also follow the code style upstream uses.
> 2) Make sure it's not going to break upstream policy.
> Examples: don't change -std=c89
> 3) Make sure it doesn't disable something for other platforms (eg, breaking
> tests for uclibc)
> 4) Make it as little change as appropriate
> 5) If at all possible, test on other platforms.

Thanks for the points.  It's good to know I'm on the right track.  I
do all of those things.  I do typically provide patches with my bug
reports.  To me, there's usually no point in saying it's broken if I
can't give a fix for it.

> The best response I had was a trivial patch for libnl (adding a couple
> headers) which I prepared, tested on musl and glibc, then sent with a
> comment that it fixed build on musl and worked on glibc. It was applied
> almost immediately.

I've had lots of patches added to software.  I've also had lots of
uncomfortable results where the developers were not very polite (and
this seems to be happening a lot more often in recent years than it
did years ago when I first started doing this).  If you know the
phrase, one bad apples spoils the whole bunch, well that certainly
applies for me.  It's made me rather uncomfortable every time I send
in a patch now and I often think twice before doing so.  I'm not sure
if someone's going to want it or if they're going to be nasty about
it.  I even preface some of my messages now by saying in case you'd
like to support this platform, here's what I had to do to get your
software to compile successfully on this system.

Sincerely,
Laura