#1 2016-12-27 02:14:23

johnraff

nullglob

From: Nagoya, Japan

Registered: 2015-09-09

Posts: 12,661

Website

Testing vs stable branch policies

This:
http://www.lucas-nussbaum.net/blog/?p=916
reminded me of our upcoming "Deuterium" packages.
More improvements and bug-fixes are being added to the "deuterium" branches of our packages, but because of a decision to release the whole set at once as a "point release", users aren't actually benefiting from them yet.

I'm starting to think once we get Deuterium out, maybe in the future we'd be better off just pushing out improvements to packages as they're made?

Of course Helium on Stretch will have to be a quantum jump, to some extent anyway.

---

...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )

Introduction to the Bunsenlabs Boron Desktop

Horizon_Brave

Operating System: Linux-Nettrix

Registered: 2015-10-18

Posts: 1,473

Re: Testing vs stable branch policies

Perhaps we should judge rather any improvement suggested, be pushed out in the main stream branch as their made. (Zirconium Updates!)   or have it be bundled in a point release ( Deuterium Updates!)  That way the more important edits can be pushed out, and anything behind the scenes, that isn't terribly impactful, and can wait, we bundled with the slower Deuterium update.

And as you said, the massive update to update to Stretch platform is the longer term one.

---

"I have not failed, I have found 10,000 ways that will not work" -Edison

guywithpups

New Member

From: Southern California

Registered: 2016-06-04

Posts: 2

Re: Testing vs stable branch policies

Personally, I think the points made in http://www.lucas-nussbaum.net/blog/?p=916 should be taken with a grain of salt. Developing the Linux kernel or a heavily used programming language is different from developing a desktop Linux distro -- the size of the audience is different as are the expectations of what constitutes "stable".  For example, I work with a number of databases at work -- when say a new version of MongoDB is released, I probably won't use it for six months or more, to give time for all of the code to mature, as our whole company relies on it being stable.  OTOH, I will probably upgrade to a new release of Bunsen Labs much sooner, as the only one impacted by issues is...me and I'm perfectly willing to Google any issues and/or post to the forums.

I'd say for Bunsen Labs it's more important to adopt release procedures that keep the work fun and enjoyable in whatever form that works best for everyone actively contributing.

Last edited by guywithpups (2016-12-27 17:19:46)

Head_on_a_Stick

Member

From: London

Registered: 2015-09-29

Posts: 9,093

Website

Re: Testing vs stable branch policies

maybe in the future we'd be better off just pushing out improvements to packages as they're made?

Yes, I think that makes sense in respect of the available resources.

The point releases are a nice idea but perhaps a more granular approach is better for this project.

EDIT:

I'd say for Bunsen Labs it's more important to adopt release procedures that keep the work fun and enjoyable in whatever form that works best for everyone actively contributing.

+1

Last edited by Head_on_a_Stick (2016-12-27 23:44:19)

---

Para todos todo, para nosotros nada