mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: musl 0.9.14 released
Date: Tue, 24 Sep 2013 13:22:03 -0400	[thread overview]
Message-ID: <20130924172203.GN20515@brightrain.aerifal.cx> (raw)
In-Reply-To: <52419D3B.1030209@gentoo.org>

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


  reply	other threads:[~2013-09-24 17:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24  6:18 Rich Felker
2013-09-24 13:51 ` John Spencer
2013-09-24 14:10   ` Luca Barbato
2013-09-24 17:22     ` Rich Felker [this message]
2013-09-24 19:13       ` Luca Barbato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130924172203.GN20515@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).