From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4064 Path: news.gmane.org!not-for-mail From: Luca Barbato Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 0.9.14 released Date: Tue, 24 Sep 2013 21:13:32 +0200 Message-ID: <5241E45C.2020901@gentoo.org> References: <20130924061849.GA3027@brightrain.aerifal.cx> <524198C5.9070502@barfooze.de> <52419D3B.1030209@gentoo.org> <20130924172203.GN20515@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380049992 31256 80.91.229.3 (24 Sep 2013 19:13:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Sep 2013 19:13:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4068-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 24 21:13:16 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VOY2t-0006sq-Sg for gllmg-musl@plane.gmane.org; Tue, 24 Sep 2013 21:13:15 +0200 Original-Received: (qmail 17876 invoked by uid 550); 24 Sep 2013 19:13:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17868 invoked from network); 24 Sep 2013 19:13:15 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130411 Thunderbird/17.0.5 In-Reply-To: <20130924172203.GN20515@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4064 Archived-At: 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