experimental branch

[Rich Brown]

Thanks to John for starting this discussion. 

I wrote the following in response to a question about the flip-side of the question - a stable release. https://forum.lede-project.org/t/current-state-and-maturity-of-the-current-code-is-there-a-issue-list/396/2

I've quoted my note below: could we open a broader discussion on the forum? Thanks.

Rich

---
And you have identified the next big question for LEDE. A while back, I wrote:

> As I watch the announcements of patches fly by on the lede-dev list, I am astonished at the backlog of work 
> that is getting resolved before my eyes. But with all this change, I wonder if the project will ever hit 
> a stable point that is "safe to use at home", with a spouse and kids who will rely on it...
> 
> We all await a decision of when LEDE will be Good Enough to declare a RC1, that will 
> lead to a stable long(er) term supported version, and to a set of predictable release cycles.

I know that the core developers are thinking about this, but I'm not aware of any public discussion yet.

There was a recent note about setting up an experimental branch for the code, but that doesn't address the flip-side, a stable branch.

It seems to me that there are two approaches to take:

	• Date-based: We'll release RC1 with whatever's working on a specific date (say, 1 Jan 2017)
	• Goal-based: We need to have kernel 4.x plus feature A, B, W, and Z working to declare RC1

Either way would be fine for me: either is a path toward something we can begin to put into production. (And that stable release provides a springboard for further experimentation: once the base system is reliable, it's more fun to try one single wacky enhancement...)

I invite a further discussion of the path to our first stable release ... in the LEDE forum. Thanks.
---


> On Nov 27, 2016, at 11:57 AM, John Crispin <john at phrozen.org> wrote:
> 
> Hi all,
> 
> i would like to start a discussion about an official experimental
> branch. the branch should be in the same git as trunk and would allow
> felix to stage his patches for proper testing in an official location.
> looking at the recent metadata patch, mac80211 updates, image building
> code, ... they all cause horrific fallout. i talked to felix about this
> and he says if he does not push people wont test which i can understand.
> 
> the same tree can also be used for kernel updates, new targets,
> busybox/toolchain updates and all other intrusive changes that we make.
> having a special branch would mitigate this fallout problem to a certain
> extend.
> 
> 	John
> 
> 
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm