I don’t agree on “let’s ship beta1/R1/whatever ASAP and then start working on R2” plan. Let’s step back a few years and look at the previous release where this is more or less what we did: “let’s ship alpha4 ASAP and then start working on beta1”. Are people using alpha4 as the stable version today? Certainly not. When they report bugs, all we can say is “download a recent nightly and try again”. And sometimes the nightlies are broken, too. They will be much more broken while R2 is being worked on, because we are going to rewrite quite a lot of the OS.
So, I don’t think this is a working solution. This is why I lean towards developping R1 and R2 in parallel, until R2 is at least ready to ship an alpha version. Until then, I don’t want to leave the poor users stuck using nightlies. There are a lot of people complaining for the lack of a stable release, but when we start discussing the details, suddenly people are like “uff, this sounds like a lot of work. It is unrealistic.”. Yes, it is a lot of work to have supported releases. This is why I’m not too keen on releasing at a very high rate like Ubuntu’s 6 month cycle or Firefox’s even crazier one. I prefer to take my time to get the details right and ship things when they are ready. I agree that the 6 years and counting since alpha4 are too much, however. Hence the plan for an R1 branch with less activity, from which it is easier to make releases from time to time, while R2 gets all the fun experimentations.
I can then get into what makes the difference between beta1 and R1:
- A stable web browser
- A working encoding/decoding system so you can watch any video and re-encode it to any format
- No more KDLs and filesystem corruptions
- Probably a few other similar things
It may seem not that far off, but these issues have been around for years.