[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130315141141.1f14e6a4.idunham@lavabit.com>
Date: Fri, 15 Mar 2013 14:11:41 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: musl setup attempt
On Fri, 15 Mar 2013 07:54:39 -0400
LM <lmemsm@...il.com> wrote:
> I have really mixed results with reporting portability bugs. More
> often than not, projects refuse to accept the bugs unless they're for
> platforms they officially support. I typically work with
> cross-platform software, but many of the cross-platform projects still
> only officially support a limited number of systems. Some of them
> have even been down-right nasty when I submit a patch to fix an issue
> for my platform. (Of course, I've run across some projects where the
> developers have been very nice too and fix things extremely quickly.)
> Am very curious if anyone else has had problems with this sort of
> thing and how you handle the situation.
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.
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.
--
Isaac Dunham <idunham@...abit.com>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
