> enforcing people to work on something probably does not work in an open > source project. People who want to work on R1 will continue working on > R1. My concern is that R2 developing is kind of blocked (R1 developer > lock). IMHO, people who would work on R2 but not necessarily on R1 have > not much incentive to do so because R1 has the priority/ lack of R2 > roadmap. As Stippi asked I don't expect a sudden surge of developers, but > if there are any we should encourage them more. We are not enforcing anyone. As several people have said, you can work on these new features either in a branch, or in the trunk without adding them to the default image as long as they are in "experimental" state. The lack of an R2 roadmap is a bigger concern, but we don't need to write any code for that. If you feel like getting this started, feel free to, and be ready to accept the bikeshedding that will come out of it. > > > - We already provide gcc2h/gcc4h/gcc2/gcc4/x86_64 versions of Haiku (not > > to mention the ones that don't even boot to the desktop). This is > > confusing > > just make it gcc4h/x86_64 and hide the rest ;-P R1 has to be gcc2h to increase compatibility with BeOS R5. Once we get that done, the first step towards R2 would be finally switching to gcc4h, and cleaning up the remaining problems on x86_64. Then we can start developping the new APIs and see where we have to make binary compatibility, or even source compatibility cuts. A lot of features can be developped without breaking anything (new classes alongside the old ones, etc) but I suspect there are some places we will have to change stuff. -- Adrien.