Parallel R1-alpha and R2-alpha branches

1

Firstly, I have no doubt that this could be interpreted to be just a continuation of an ongoing saga - and maybe the mailing list would have been a better place to post this - but since it is just to gauge interest and current perception, I chose to spare the formality.

At the moment, the Haiku project currently has the goal of reaching (ultimately) a BeOS-compatible R1, as a base for a new, partially-backwards-incompatible R2 release.

Whilst I can understand that goal, I see that there are those that feel that the shorter term goal of keeping binary compatiblity with BeOS (until R1) is acting as a large pair of hands holding back the future progress of this (originally clean-slate) OS.

Project elevator notwithstanding, has anyone given any thought to the idea of having two active branches? The developers that want their old BeOS apps to run can then focus on the R1-alpha branch, while those that want to drop legacy compatibility could at the same time focus on new development on R2-alpha, using a single compiler ABI (whether GCC5 or LLVM).

That way, since development resources are limited, R2-alpha would be free to advance as a branch in its own right, and those developers that really want to get R1 released (and keep their older software compatibility) can do so by putting the work in themselves to port code back from the R2-alpha branch as they see fit, making sure it works for GCC2.

At first, this approach would seem wasteful - since one could ask themselves why not just make the code compatible with R1 and R2 in the first place - but the point is, with a separate R2-alpha branch, it is no longer the primary goal of “Project R2” to maintain compatibility, freeing it to move ahead with its own goals.

It’s sort of a survival-of-the-fittest approach, sure. But it would free R2 from the shackles of R1’s historical compatibility requirements and allow those developers that really care about R1’s compatibility to choose to put their time into the R1-alpha branch as they see fit.

Has this been discussed before? Obviously there are positives and negatives to what I’ve just said - but do the positives outweigh the negatives?

2

We have an R2 milestone in Trac where we put the tickets that require a binary compatibility drop. The list is here:
https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=reopened&status=new&group=status&milestone=R2

I'm not sure these 10 items are very urgent in the top priority list. If people have more things they want to do that require compatibility breakage, the least they should do is create tickets in the R2 milestone. If they aren't even bothered to do that, I assume they will also not be motivated to actually implement the new features.

So, after all these years working with Haiku, I still don't understand how the binary compatibility can be a problem. We don't want completely isolated R1 and R2 branches, that are not compatible with each other, because this would create two completely separate "worlds" with different apps ecosystem. Resulting in much frustration for users, because they would have to chose between R1, the one that run all the old and classic apps, and R2, the one that run the new and fresh apps.

What I would suggest instead is to make not a branch, but extend the system so the two versions of the API can live side by side. You could start work on "interface kit 2" for example, put it in the R2 namespace so the C++ symbols don't conflict, and put it in a libinterface.so.2 or so. Apps could then start to use this, while the good old libbe.so is still there for apps that haven't switched to the new system.

There is still the downside of splitting apart our already small developer base. It's a bet that new and exciting work on a shiny C++11 API would suddenly attract several dozen more developers to compensate for this. Or that the secret plan for the R2-people is to reach a stable release of their API before the R1 one is ever finished, maybe?

So, what are the roadblocks that would prevent work on the R2 API without a fork/branch of the OS? Note that I would, however, still create an R1 "stable" branch before that work starts, and use it for beta1 and onwards releases. Maybe it's time we start doing this, but it has been waiting on the package infrastructure to be setup (what we have currently isn't fit to working with multiple git branches).

3

Unfortunately as PulkoMandy said, maintaining an R2 branch right now isn’t feasible, and I guess, would have the final effect of being the final cut for R1 too. But at the same time, people is willing to begin looking at the future of the project, being a developer from just a few months I personally understand this feelings very well, or at least I can understand the confusion.It’s a bit difficult to contribute and it seems a large part of developers are (reasonably) keeping the project into it’s own “good old rules”. It seems new devs are someway scared so that after a few months of activity they disappear. I think not having a development plan is a problem. Haiku Inc. is not publishing contract plans to boot the development on the final release, this has been discussed various times and we know why it’s this way. I think on a hand the project is strongly held with trademarks, rules etc. internally the cathedral is exactly going to operate as a bazar. So, I’m not surprised that people want to go away from R1, maybe in the hope that a renaissance would convert the maggot into a butterfly. So I think we should just release the beta1, the more the time goes, the more features we will be lacking.

Relating the maintainability of R2 API in R1 branch, from the point of view of media_kit I don’t think it’s feasible. Due to various changes needed and complexity of the code, I am not willing to increase it’s complexity because I have to maintain the old code. The only solution would be to rewrite the media_kit backend to use the new server, but in this case I doubt a 100% compatibility is achievable that makes this out of any R1 definitions.

4

I see the logic in philcostin’s approach, but I don’t know if the resources are available to do that. Two branches would be great, since I suppose not everyone feels backward compatibility is a priority. I for one would like it, but it isn’t necessary.

I see the pros as being one branch having freer reigns to move forward, unencumbered by backward compatibility issues, thus having more breakthroughs. The negative aspect is a fragmentation of resources and even worse, a fragmentation of the community and Haiku at large. Both branches could eventually be incorporated into the final release. Again, this would only work with the right amount of resources, which I think isn’t there.

Do I get this right?

5

Not sure what splitting the development effort would accomplish. There appears to me two different approaches to an OS: desktop simplicity OR production capable complexity. As a really old mainframe production programmer (COBOL ca. 1965) I never thought the desktop was the place for the latter. Several discussions with Bill Gates and Paul Allen did not dissuade me from this opinion and I still not persuaded that the desktop is the place for a production OS.

Why then not return (or remain if you will) to the original intent of BeOS? A simple and elegant desktop with good (ok, superior) graphics would be far better than a be-all, do-all, complex, difficult to maintain, clumsy, bulbous, buggy, etc. desktop OS. For the gamers, an engine like Steam could be built but not as a part of the OS? For the office, an engine like Liberoffice or OpenOffice with “hooks” into the OS?

It seems to me we traded a headache for an upset stomach. If we build a really tight, simple OS with hooks, we have the best of all worlds…

Toby Hilliker
Does it bother anybody that the mime is talking?

6

[quote=PulkoMandy]
So, after all these years working with Haiku, I still don’t understand how the binary compatibility can be a problem. We don’t want completely isolated R1 and R2 branches, that are not compatible with each other, because this would create two completely separate “worlds” with different apps ecosystem. Resulting in much frustration for users, because they would have to chose between R1, the one that run all the old and classic apps, and R2, the one that run the new and fresh apps.[/quote]

For a new entrant like BeOS it’s attractive to assert that everybody else is burdened by compatibility which makes everything slow and hard to use. This turns a problem (BeOS doesn’t run existing software) into a virtue (BeOS leaves behind all that crap). But of course a few years down the line “let’s throw away all our applications and start over” seems like crazy talk. Nevertheless, the idea that Haiku isn’t burdened by a legacy remains a popular theme with fans, so you will find people who’ve imagined Haiku R2 will throw everything away and start afresh. Haiku can’t deliver the contradictory promises that have been made. Nobody technical will have expected it to, but some fans are going to be disappointed.

But actually there is more of a dilemma than immediately appears. Over the last 15 years Haiku’s developers have added various features that aren’t part of BeOS R5 yet also aren’t called out as stable Haiku R1 features. Software has begun to depend on those features, yet they’re described as “not finalized” so programs using them might break tomorrow, or in Haiku R1, or in a hypothetical “backwards compatible” Haiku R2. That’s a nasty spot to put application developers in.

The BLayout stuff is one example. Without it you’re reduced to writing 1980s-style grid pixel GUIs, this was already one of the worst things about BeOS twenty years ago. But BLayout is labelled (at least everywhere I can find) “not finalized” and Haiku developers feel comfortable still tinkering with it, so you can’t depend upon applications which use it still working for any length of time.

Perhaps worse, Haiku still doesn’t have the thunking layers you’d normally deploy in an OS to let applications from different ABIs interoperate. The most fundamental is the kernel thunking needed to let 32-bit apps (whether from the BeOS R5 ABI or a new one) run on the same Haiku as 64-bit apps, but there is also a thunking layer needed for “add on APIs” like those used by the Translation Kit, otherwise an old add-on doesn’t work with a new application and vice versa.

7

[quote=NoHaikuForMe]
For a new entrant like BeOS it’s attractive to assert that everybody else is burdened by compatibility which makes everything slow and hard to use. This turns a problem (BeOS doesn’t run existing software) into a virtue (BeOS leaves behind all that crap). But of course a few years down the line “let’s throw away all our applications and start over” seems like crazy talk. Nevertheless, the idea that Haiku isn’t burdened by a legacy remains a popular theme with fans, so you will find people who’ve imagined Haiku R2 will throw everything away and start afresh. Haiku can’t deliver the contradictory promises that have been made. Nobody technical will have expected it to, but some fans are going to be disappointed.[/quote]

Where did you read those jokes? Is it BeDope? Be even if rewrote pieces of it’s own OS at it’s release the most important ones were already kept binary compatible such as the old sound API. If someone referred R2 as breaking the ABI, it was because of compiler switch, no one ever imagined that R2 will be done from scratch.

This is not true, the layout API is public and any future development will be done maintaining binary compatibility.

8

[quote=33Nicolas]I see the logic in philcostin’s approach, but I don’t know if the resources are available to do that. Two branches would be great, since I suppose not everyone feels backward compatibility is a priority. I for one would like it, but it isn’t necessary.

I see the pros as being one branch having freer reigns to move forward, unencumbered by backward compatibility issues, thus having more breakthroughs. The negative aspect is a fragmentation of resources and even worse, a fragmentation of the community and Haiku at large. Both branches could eventually be incorporated into the final release. Again, this would only work with the right amount of resources, which I think isn’t there.

Do I get this right?[/quote]

If we were talking of a commercial company where the manager could decide to split up the team so that half will take care of the stable release and half will take care of creating the ground for future features that’d be OK, but we are in completely different situation where the system is carried by volounters. Actually the package manager added a great delay to the release, and I would like to avoid adding anything that might possibly delay it to the infinite. This apply to both creating an R2 branch, and including R2 API in Haiku.

9

Thanks for the input guys.

I’m not necessarily advocating actually branching for real, but did want to raise the concept to see where the land lies in terms of what people feel the future is going to look like.

In the past, there always seemed to be the shared goal of R1 being BeOS compatible (first), with R2 coming after and not needing to be compatible. However, it seems to me that the community of developers as a whole is divided on whether they see R2+ being able to run GCC2/BeOS binaries.

Even though some people are saying “Let’s get to R1 first, then break compatibility”, I suspect they are doing that as a motivator for people to help get to R1, rather than actually wanting to drop compatibility - and actually, if we get to R2, dropping compatibility will be the last thing on their mind and I can understand that. But if that’s the case, let’s plan to do that - otherwise there will be arguments, splits and personality conflicts later on.

I do agree with PulkoMandy that having V2 APIs - where it makes sense to do so - is a valid method of keeping the project together, making sure the BeOS legacy programs are still available on current (R2+) versions - and if others also agree with that, it would provide a clearer consensus of what the goals are for the future.

Although:

  • The GCC2 ABI
  • The non-availability of C++11 and later
...are not the only things that could be improved by a break in compatibility somewhere, having a second version of the same libraries installed, compatible with a newer version of the APIs (and in a different namespace) as PulkoMandy said, would be fine. Maybe that's what's already happening now.

Some people worry that if there were a separate R1 branch, compatibility would die out. But that’s exactly what would happen anyway if R2 doesn’t have a plan to keep backwards compatibility, as was mentioned in my 3rd paragraph above. Let’s face it, more people would be disappointed at that (not being able to run their old software on their shiny Haiku R2+) than the number of people that felt let down by side effects of the inclusion of package management.

Lastly, following on from NoHaikuForMe’s thoughts, since Haiku would theoretically, given enough manpower, run on (and have packages compiled for) ARM/Sparc/Power/amd64 etc, maybe some kind of thunking mechanism / IA32 emulation could be present so that the back-catalog of older 32-bit IA32 / GCC2 software would also run on other platforms to which Haiku is ported, even if a little slower.

EDIT: I probably should have re-read this thread earlier - I assume the situation remains the same: https://www.haiku-os.org/news/2009-01-31/haiku_finally_gets_a_native_gcc4_full_story_inside

10

Then I suggest Haiku’s documentation should be updated to reflect this fact, and also you might want to make a public announcement about it, maybe a blog post.

11

[quote=Barrett]Where did you read those jokes? Is it BeDope? Be even if rewrote pieces of it’s own OS at it’s release the most important ones were already kept binary compatible such as the old sound API. If someone referred R2 as breaking the ABI, it was because of compiler switch, no one ever imagined that R2 will be done from scratch.
[/quote]

BeOS R3 and BeOS R4 are completely incompatible on Intel. It doesn’t matter to your users what excuse is dreamed up, whether it’s about compilers or the Northern Lights, they just know their old stuff doesn’t work.

The definition of “the most important ones” was chosen by Be as it suited them, remember the 3DKit? It was a big deal, one of the major features Be touted for some time, vitally important to BeOS and… abandoned by BeOS R5 so that’s why Haiku doesn’t try to re-implement it.

To get some idea what fans thought Haiku might do in R2 check out the Glass Elevator. Totally abolishing files, radically different user interfaces, nobody said “Woah, woah, we can’t consider anything unless it’s backwards compatible, this isn’t a clean slate” because all the people actually doing any programming considered the Glass Elevator as primarily a way to get rid of people too excitable to focus on getting anything actually done.

12

Obvious choice as OpenGL was one of the two standards from R4 and later, and obviously they would have trouble maintaining it.

[quote=NoHaikuForMe]
To get some idea what fans thought Haiku might do in R2 check out the Glass Elevator. Totally abolishing files, radically different user interfaces, nobody said “Woah, woah, we can’t consider anything unless it’s backwards compatible, this isn’t a clean slate” because all the people actually doing any programming considered the Glass Elevator as primarily a way to get rid of people too excitable to focus on getting anything actually done.[/quote]

You are a very imaginative person.

[quote=NoHaikuForMe]
Then I suggest Haiku’s documentation should be updated to reflect this fact, and also you might want to make a public announcement about it, maybe a blog post.[/quote]

Still, false.

13

Then I suggest Haiku’s documentation should be updated to reflect this fact, and also you might want to make a public announcement about it, maybe a blog post.[/quote]

There were lots of blog posts about the layout API during its development. Though, not specific announcements of the availability of the API: czeidler's blog | Haiku Project

14

Quite logically, making the new APIs/ABIs stable (layout API, but also the locale kit, the services kit with HTTP, etc) would be done as a kind of “freeze” which should happen at the time beta1 is released. As long as we were not beta, we were free to make changes as needed to these. When we reach beta, we have to freeze the ABIs for the things we plan to ship (the layout kit is ready for that, the locale kit may be ok, the HTTP stuff definitely needs a rewrite if we want to make it part of the official stable APIs.

Once we have frozen these things, the OS will enter a stage of bugfixong only in the beta1 branch. If people are not willing to help with that, and prefer to continue work on new APIs, they can do so in the trunk. And when they start to break ABIs, we can see about how to keep compatibility. Maybe not with BeOS, but at least with Haiku-R1. This is an open question for me and also depends on the timeframe and wether betas and R1 really get us 3rd party developers writing a lot of new cool apps to replace the old rusty BeOS stuff.

15

[quote=Munchausen]
There were lots of blog posts about the layout API during its development. Though, not specific announcements of the availability of the API: https://www.haiku-os.org/blog/czeidler[/quote]

There certainly are lots of blog posts about the API, for example there’s this one:

“Layout API is not yet finalized” (their emphasis)

But Adrien (“Pulkomandy”) has stepped in too, since Adrien and Barrett are both Haiku core developers I’ll let them argue among themselves about what Haiku’s actual policy is or should be.

16

[quote=NoHaikuForMe]
There certainly are lots of blog posts about the API, for example there’s this one:

“Layout API is not yet finalized” (their emphasis)

But Adrien (“Pulkomandy”) has stepped in too, since Adrien and Barrett are both Haiku core developers I’ll let them argue among themselves about what Haiku’s actual policy is or should be.[/quote]

The API is in public headers, thus not private, and Haiku R2 will be binary compatible.

17

[quote=Barrett]
The API is in public headers, thus not private, and Haiku R2 will be binary compatible.[/quote]

Sorry, maybe I wasn’t clear enough. I meant you should argue about it among yourselves in private.

18

[quote=NoHaikuForMe][quote=Barrett]
The API is in public headers, thus not private, and Haiku R2 will be binary compatible.[/quote]

Sorry, maybe I wasn’t clear enough. I meant you should argue about it among yourselves in private.[/quote]

I don’t hear any argument. Users on this board do not have to do what you tell them.

19

[quote=Munchausen]

I don’t hear any argument. Users on this board do not have to do what you tell them.[/quote]
I think you missed the joke in there :smiley:

But anyway both sides have valid point
one side you can use the Layout API (i am not really happy with … :slight_smile: )
But on the other side as long as its in private it feels always a bit risky… because
the “barrier” for Haiku developers to change the API there seems a little lower :slight_smile:
Best example is BColumnListView … where differen projects used a
version form the different sources
because it was in private/experimantal…

But on the other hand i dont think it will change a lot… so we are on the save side
its just a matter of decide to make it “mature”.