On Tue, 05 Mar 2013 10:20:26 +1300, <pulkomandy@xxxxxxxxxxxxx> wrote:
On 2013-03-04 at 21:57:41 [+0100], Clemens <clemens.zeidler@xxxxxxxxx> wrote:fully agree. However, I have the feeling it is harder do that in the main branch. At the moment it might be easier but when it comes to a release it will become hard again. A second branch would be helpful to try stuff out,i.e. things that not can be developed entirely in a branch. For example, the last window management discussion (maximizing, resizing, zooming...)One can implement such stuff in a branch but if nobody is using and trying it, its pointless. There must be some user feedback like: "this feature isgood, the other one is useless/annoying..."You can do this as an extra decorator, without branching at all. Just thesame way Stack and Tile was developed. Or you can do it in your own branchand make a binary package that people can try out. Looncraz does that on our mailing lists and he seems to get some useful answers.
Yes enabling features temporary in the main branch would work as well. Binary packages or extra images might be a different thing cause you explicit have to take an effort to test this features, just peeking at a feature is more difficult.
I see the point that much stuff can be done in the main branch, but sometesting stuff just do not fit there. I'm also not fixed on a R2 branch but some platform to do research on new stuff would be good. A R2 branch would have the advantage that all R2 developers automatically become guinea pigs;-) Furthermore, official nighties would make it easier for non-developers. Hope you got the idea...This essentially means less people working in the R1 branch. This is a goodway to let that branch aside. By enforcing everyone to work on the same branch, we enforce several things :- People try not to completely break the build with their changes. Either working in their own branch, or not enabling their WIP code to be includedin the image.- Developers stay focused towards the R1 goal. Even if sometimes it's funor motivating to work on newer features, it's important to keep an eye onthe release target. And there are a lot of bugs we should fix before R1 canhappen
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 already provide gcc2h/gcc4h/gcc2/gcc4/x86_64 versions of Haiku (notto 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 Regards, Clemens