[haiku-development] Re: Beta1 and R1 release plan
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 3 Nov 2014 15:27:34 +0100
On Mon, Nov 03, 2014 at 02:34:56PM +0100, Axel Dörfler wrote:
> >The way I see things, is that our master branch is a playground for
> >developers. That doesn't mean R2 is. An R2 branch can be split out of
> >the master and stable features merged there. We can then plan a release
> >at any time knowing that we have a stable branch to work from. Starting
> >the R2 work from the R1 branch instead would mean more work in catching
> >up with trunk and I'm not sure what the gains are.
>
> Maybe I did not made myself clear enough: without keeping those branches
> connected, as a user, you won't have any functional update of Haiku for the
> years to come, as you likely would not want to live on the bleeding
> playground edge.
> Before making master a playground, I would prefer a Linux like approach, ie.
> a next (playground), and a stable repository, and establish a review process
> for the latter only (IIRC Oliver is still investigating this).
> Still, even playground should only receive mostly complete features. That
> other playground should stay the local/github repository of the developers.
Maybe I'm mising something here, but it seems to be mostly a difference
in branch naming and how the R2 branch is created.
Yes, in the original plan, the R1 branch would be a dead-end. It is kept
there for security updates and bugfixes to R1, until R2 is out. The idea
being that we continue to support users running R1, and fixing bugs for
them, while on the R2 branch we prepare and publish alphas and betas.
The two branches thus live in parallel for some time (as short as possible),
so there is an R1 release for users, which is bug-free, and an R2
pre-release for developers, which proably has some bugs but where they
can experiment with the new R2 features.
Sure, if R2 keeps an R1 wrapper that can be made stable by all means,
there is little need for this. But this requires a stricter control on
merging things to the R2 branch, hence a change of workflow (next/master
like Linux, Gerrit-style, and/or pull requests from devs individual
repos).
>
> >As far as I'm concerned, source compatibility would be enough.
>
> For me, this would not be acceptable at all (as I said, not necessarily R1,
> but in the long run). While you position yourself clearly, I'd rather like
> to see a discussion of why source compatibility would be enough. Are there
> any objections to the notion that 1) one repository to rule them all is
> impossible, and that 2) not having binary compatibility sucks as soon as you
> have more than one repository?
>
> Source compatibility is, to a certain degree, nice, but doesn't help a
> thing. With this.
We are in a situation different from the Linux one where there are
dozens of distributions to care for. I think it is reasonable to ask
Haiku application developers to compiler their app for R1 and R2 during
the R2 testing period. This doesn't need a single repository, nor does
it needs binary compatibility from R1 to R2. It does, however, need
binary compatibility from R1 to its bugfix releases (R1.1, etc) and from
R2alpha1 to R2 (including anything in between). So we still have to take
care before making APIs public, and include the FBC padding or other
future-proofing measures in all new public classes.
>
> >While at first the master branch may see a lot of disrupting changes, at
> >some point it will have to get into a more stable state and start
> >pushing out alphas, betas and stable releases. The availability of
> >alphas and betas means 3rd-party devs can test their apps there, fix
> >them if needed, and get them up to date and ready when the final R2 gets
> >out.
>
> We see how well that works in the Linux world. Or at Mac OS X which has seen
> at least a number of compatibility issues in the past.
Again, the situation is very different from Linux. In the Linux
ecosystem the dependencies for any software are updated at random times
and out of sync with each other, it is not possible for application
developers to take care of this. As a result the work of getting this
fixed is moved into the hands of people populating the repositories for
each distribution.
On Mac OS X, there is also a difference: each piece of software is
distributed with all the dependencies in a bundle. This means a "bundle
version X + system version Y" can be fully tested, but system version
Y+1 may need an update to the whole bundle. As we are working with package
and dependencies instead, we can actually update the dependencies and
directly fix a package. For example, let's say a system update requires
a change in SDL (this happened in Mac OS X some years ago). On OSX, all
apps using SDL bundle their own version, thus they are all broken and
need to be updated individually. On Haiku, you just replace the SDL
package in the repositories (or your local install) with a fixed one,
and suddenly all SDL based applications work again.
> >By putting beta1/R1 in a branch, the idea is to free the master branch
> >of those constraints. It is not to free R2 of those constraints.
>
> Sure, that one should end up in a branch. But as you know, it *is* plenty of
> work to keep it up to date. You shouldn't be the only one to do that work,
> or you'll be burned out in a few months.
I have proposed a bugfix-only approach to the R1 branch, to keep the
amount of work maintaining it low. for R2 I'd very much prefer a
workflow change that allows a stable trunk from which it's easy to
branch out releases at any time.
>
> >To sum it up:
> >- Beta1 and R1 are made from the same branch, with a feature freeze and
> > only bugfixes from one to the other
>
> We agree on that much :-)
>
> >- R1.1 and subsequent releases (if needed) are made from that same
> > branch, with more bugfixes, and possibly with a timed schedule (every
> > 3, 6 or 12 months for example) - or as rolling updates to the
> > repositories. There may be a limited set of new features here but with
> > very very careful review to avoid any regressions.
> >- R2 can be branched either from the R1 branch, or from trunk at some
> > later point. This one can integrate more new features and other
> > breaking changes. There probably needs to be an alpha/beta phase for
> > it. Some kind of compatibility with R1 could be included.
>
> Following my suggestion, this would look like this:
> - After R1 is released, we switch master to move GCC2 support to a legacy
> folder. Once that is done, it will be merged into the R1 branch, too (IOW,
> this branch (or one based on it) would become our release branch also for
> future releases). This will also make merging changes a lot easier.
> - R2 would happen in the GCC4 part of our tree. All applications & servers
> that come with Haiku would be switched to GCC4 (again, this would affect the
> release branch, too).
> - This way, we could deliver frequent updates to Haiku without having to
> worry about binary compatibility too much for quite some time to come.
Ok, this is fine but I would like to keep the R1 and R2 branches
separate, so we can continue bugfixing R1 until R2 is ready. The reason
for this is that as a 3rd-party app developer (yes, I'm also that) I
already switched to compiling my apps with gcc4 a few years ago, and I'm
fairly sure I'm not alone in that case. We have already failed at this
"gcc2 is the stable ABI" thing, and there is little use to me in trying
to keep it alive anymore, we're not even fooling anyone with it. Let's
just admit this and live with the consequences, and maintain the R1-gcc4
ABI as well as we can, until 3rdparty devs can jump into the R2 ship.
As I already mentioned, most of the apps Haiku users are running are not
old binaries from BeOS days. They use Qt and Java apps, and new apps
such as DocumentViewer or WebPositive for example. And whatever was
left from the BeOS legacy has been opensourced thanks to the
HaikuArchives project. If you are still running closed source BeOS apps
in 2014, it is really time to consider how to migrate away from those. A
commonly mentionned one is GoBe Productive, which can be partially
replaced by Sum-It and Abiword. I would rather spend time in getting
these open source apps in better shape, than trying to keep the old
unsupported ones running forever on Haiku. Especially with x86_64 and
ARM ports already running or just around the corner.
Or to phrase it more clearly: R1 as originally designed, with only a
gcc2 stable ABI, already is a dead-end. At this point having to support
gcc2 in many parts of the system is doing more harm than good to the
project (we can't use C++11; we have frankeinstein libc that doesn't
quite work; we waste time getting libs to compile with gcc2 (ICU) or
use outdated versions (ffmpeg), or even remove features from our stable
API because there is no sane way to get them working (webkit/BWebView).
And it's hard to tell how many developers have turned away from Haiku
(either as core contributors or 3rdpparty devs) because of this. This is
an attempt to stop this madness and save the project before everyone
leaves.
I was fine with gcc2 until some years ago, but with C11, C++11,
and C++14 missing, and even Microsoft getting reasonable C99 support,
this is not a sustainable approach anymore. We can't seriously pretend
we expect people to write their apps in C89 and C++98 for Haiku, the
new, lean and clean operating system. This is just a bad joke and the
opposite of one of BeOS design goals (breaking with legacy).
So, I'm fine with someone stepping up to take care of the R1-on-R2
compatibility layer. There is nothing wrong in doing it if someone wants
to. But I have little use for it and I think it is safer and easier for
me to work on keeping a feature-frozen R1 branch up to date until R2
gets released.
--
Adrien.
Other related posts:
