musl 0.9.14 released

musl 0.9.14 released

[Rich Felker]

Hi,

Earlier today I posted the release of musl 0.9.14:

    The result of major bug-hunting. Fixes a regression in
    installation of the dynamic linker symlink when DESTDIR is used,
    rare deadlock in libc-internal locking, incorrect dynamic linker
    fallback to built-in search paths in certain error cases, popen
    failures when the caller has closed stdin or stdout, deadlock and
    memory-corruption issues in multi-threaded set*id and setrlimit
    operations, and multiple low-impact bugs in math functions and
    other components.
    
    http://www.etalabs.net/musl/releases/musl-0.9.14.tar.gz

This release was a little later than I would have preferred; I had
hoped to release it last weekend, but held off for a bit while we
tracked down some additional bugs and potential-bugs. This has put the
roadmap for 1.0 a little bit behind, but the bright side is that we
found and fixed a lot of bugs, including some that had been elusive
for a long time.

I still think we should have one more release, 0.9.15, before calling
this 1.0. My intent is to continue the bug-hunting, based on an
approach of:

- Writing and running more test.
- Source level analysis (grepping, static analysis, etc.).
- Tracking down application build failures and any mysterious runtime
  problems in applications.

I'll continue working on the documentation too, in hopes of including
a presentable version in the next release tarball so it can get some
public review before 1.0. At this point my leaning is to hold off on
any other functional changes aside from bug fixes before 1.0; there
were a few items on the Roadmap as secondary targets which would have
been nice, but they're not critical and stabilizing for 1.0 is more
important.

Sometime soon I also want to focus on what the development and release
model post-1.0 will be, especially whether we'll aim to maintain a
'stable' branch with minimal new features alongside new development.

Rich

Re: musl 0.9.14 released

[John Spencer]

On 09/24/2013 08:18 AM, Rich Felker wrote:
>
> I'll continue working on the documentation too, in hopes of including
> a presentable version in the next release tarball so it can get some
> public review before 1.0. At this point my leaning is to hold off on
> any other functional changes aside from bug fixes before 1.0; there
> were a few items on the Roadmap as secondary targets which would have
> been nice, but they're not critical and stabilizing for 1.0 is more
> important.

sounds like a good plan.
especially the stateful iconv feature could lead to undesired and hard 
to detect breakage.

>
> Sometime soon I also want to focus on what the development and release
> model post-1.0 will be, especially whether we'll aim to maintain a
> 'stable' branch with minimal new features alongside new development.

having a stable branch which only gets backports of bugfixes makes sense 
if we aim for inclusion in conservative distributions.
if nothing else, it signals that we care about stability.
otoh it's much more work to maintain...

thinking about stability, it also seems necessary to strengthen musl's 
web infrastructure. we should at least have links to download mirrors 
like http://foss.aueb.gr/mirrors/linux/musl-libc/ (not up-to-date, it 
seems, thus adding ivan to CC) or automatically updated git mirrors like 
ftp://ftp.barfooze.de/pub/mirror/musl-libc.org/index.html
, http://repo.or.cz/w/musl.git or https://github.com/jhuntwork/musl

Re: musl 0.9.14 released

[Luca Barbato]

On 24/09/13 15:51, John Spencer wrote:
>> Sometime soon I also want to focus on what the development and release
>> model post-1.0 will be, especially whether we'll aim to maintain a
>> 'stable' branch with minimal new features alongside new development.
> 
> having a stable branch which only gets backports of bugfixes makes sense
> if we aim for inclusion in conservative distributions.
> if nothing else, it signals that we care about stability.
> otoh it's much more work to maintain...

If you want a stable branch I found _really_ useful having tags such as

CC: musl-stable@musl-libc.org

But you need at least 2 people doing the actual backporting weekly.

lu

Re: musl 0.9.14 released

[Rich Felker]

On Tue, Sep 24, 2013 at 04:10:03PM +0200, Luca Barbato wrote:
> On 24/09/13 15:51, John Spencer wrote:
> >> Sometime soon I also want to focus on what the development and release
> >> model post-1.0 will be, especially whether we'll aim to maintain a
> >> 'stable' branch with minimal new features alongside new development.
> > 
> > having a stable branch which only gets backports of bugfixes makes sense
> > if we aim for inclusion in conservative distributions.

And embedded developers -- they don't want to waste their time heavily
testing a new version with lots of additional features they don't need
just to fix a bug that might affect their products.

> > if nothing else, it signals that we care about stability.

Yes, this is probably the most compelling reason.

> > otoh it's much more work to maintain...

Agreed. Hopefully we can minimize this.

> If you want a stable branch I found _really_ useful having tags such as
> 
> CC: musl-stable@musl-libc.org

How is this a "tag"?

> But you need at least 2 people doing the actual backporting weekly.

I'm skeptical that it would be that much work. Unlike lots of
projects, musl's codebase intentionally avoids a lot of
interdependence between modules. If, for example, 80% of bug fix
commits apply cleanly to both branches, they could just be committed
to both directly, and that would probably leave, on average, less than
one commit per week that needs to be backported but doesn't apply
directly.

If the majority of post-1.0 effort is spent on adding features and
simplifying/refactoring existing code, I would tend to expect even
fewer bug-fix commits, but the refactoring might make a higher
percentage of them require backporting effort.

Rich

Re: musl 0.9.14 released

[Luca Barbato]

On 24/09/13 19:22, Rich Felker wrote:
> On Tue, Sep 24, 2013 at 04:10:03PM +0200, Luca Barbato wrote:
>> On 24/09/13 15:51, John Spencer wrote:
>>>> Sometime soon I also want to focus on what the development and release
>>>> model post-1.0 will be, especially whether we'll aim to maintain a
>>>> 'stable' branch with minimal new features alongside new development.
>>>
>>> having a stable branch which only gets backports of bugfixes makes sense
>>> if we aim for inclusion in conservative distributions.
> 
> And embedded developers -- they don't want to waste their time heavily
> testing a new version with lots of additional features they don't need
> just to fix a bug that might affect their products.
> 
>>> if nothing else, it signals that we care about stability.
> 
> Yes, this is probably the most compelling reason.
> 
>>> otoh it's much more work to maintain...
> 
> Agreed. Hopefully we can minimize this.
> 
>> If you want a stable branch I found _really_ useful having tags such as
>>
>> CC: musl-stable@musl-libc.org
> 
> How is this a "tag"?

Something-Like-This: IsAtagInGit

Or more useful:

Bug-Id:

> I'm skeptical that it would be that much work. Unlike lots of
> projects, musl's codebase intentionally avoids a lot of
> interdependence between modules. If, for example, 80% of bug fix
> commits apply cleanly to both branches, they could just be committed
> to both directly, and that would probably leave, on average, less than
> one commit per week that needs to be backported but doesn't apply
> directly.

I was as well till I tried to maintain two major versions up to date and
released more or less timely.

Hopefully musl won't have _that_ many bug to fix being the code much
cleaner from start.

> If the majority of post-1.0 effort is spent on adding features and
> simplifying/refactoring existing code, I would tend to expect even
> fewer bug-fix commits, but the refactoring might make a higher
> percentage of them require backporting effort.

Yup, that's why I'm afraid =)

lu