Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 16 Mar 2013 18:58:25 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl setup attempt

On Fri, Mar 15, 2013 at 02:11:41PM -0700, Isaac Dunham wrote:
> 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.

Thank you. This email belongs on the wiki.

Rich

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.