Doing a release?

[Carmelo Amoroso]

Hi

Il 20 settembre 2013 11:37:47 Sedat Dilek <sedat.dilek at gmail.com> ha scritto:
> On Fri, Sep 20, 2013 at 8:41 AM, Rich Felker <dalias at aerifal.cx> wrote:
> > On Wed, Sep 18, 2013 at 06:44:15PM +0200, Thomas Petazzoni wrote:
> >> Dear Khem Raj,
> >>
> >> On Wed, 18 Sep 2013 09:11:43 -0700, Khem Raj wrote:
> >>
> >> > > It'd be really nice if uClibc adopted a slightly more frequent
> >> > > release schedule, to more easily allow downstream users to benefit
> >> > > from improvements/fixes.
> >> >
> >> > I think, if we decide to do releases biannually maintaining branches
> >> > for long time can be avoided. To get started I think lets start by
> >> > planning for a 0.9.34 and then everyone sending the pending patches
> >> > for subsequent 0.9.35 and so on.
> >>
> >> Since I'm not a uClibc contributor, it's certainly quite easy for me to
> >> just speak, but I would like to advocate for a time-based release
> >> schedule. I believe that for many projects, time-based release
> >> schedules create a rhythm, that provides well-known deadlines and
> >> encourages the entire community to meet those deadlines.
> >
> > Agreed. Time-based release schedule has worked very well for musl,
> > too, but with much shorter release intervals, usually 1-2 months.
> >
>
> I recommend to read Martin's PhD Thesis on this topic.
> ( Martin is a longterm Debian maintainer and was also Debian project
> lead, so he should know of what he is talking. )
>
> [ QUOTE ]
>
> Quality Improvement in Volunteer Free and Open Source Software
> Projects: Exploring the Impact of Release Management
>
> Martin Michlmayr, University of Cambridge
>
> Abstract
>
> Free and open source software has had a major impact on the computer
> industry since the late 1990s and has changed the way software is
> perceived, developed and deployed in many areas. Free and open source
> software, or FOSS, is typically developed in a collaborative fashion
> and the majority of contributors are volunteers. Even though this
> collaborative form of development has produced a significant body of
> software, the development process is often described as unstructured
> and unorganized. This dissertation studies the FOSS phenomenon from a
> quality perspective and investigates where improvements to the
> development process are possible. In particular, the focus is on
> release management since this is concerned with the delivery of a high
> quality product to end-users.
>
> This research has identified considerable interest amongst the FOSS
> community in a novel release management strategy, time based releases.
> In contrast to traditional development which is feature-driven, time
> based releases use time rather than features as the criterion for the
> creation of a new release. Releases are made after a specific
> interval, and new features that have been completed and sufficiently
> tested since the last release are included in the new version.
>
> This dissertation explores why, and under which circumstances, the
> time based release strategy is a viable alternative to feature-driven
> development and discusses factors that influence a successful
> implementation of this release strategy. It is argued that this
> release strategy acts as a coordination mechanism in large volunteer
> projects that are geographically dispersed. The time based release
> strategy allows a more controlled development and release process in
> projects which have little control of their contributors and therefore
> contributes to the quality of the output.
>
> [ /QUOTE ]
>
> IMHO, a six months release cycle has shown good success - for
> developers and endusers.
> The trend in developing seems to go to a 3-months-cycle.
> The Linux-kernel as an example has proven this.
>
> Can't say if something like "Linux-next" is do-able and makes sense as
> "uClibc-next".

I think that most of users of uclibc tends to rely upon stable release 
taken from distro builder (buildroot open embedded and others) so master is 
acting as the next for the kernel.

> Fact is, a lot of kernel sub-trees (features) "mature" in Linux-next
> before they enter upstream.
>

We had similar experience with prelink and nptl branches but it required 
much more effort at merging than integrating the features in master directly.

> Just my 0.02EUR.
>
> [1] http://www.cyrius.com/publications/michlmayr-phd/

Interesting reading

Cheers
Carmelo
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc


Inviato con AquaMail per Android
http://www.aqua-mail.com