[haiku-development] Re: UI discussion (was "WebPositive misleading tool tip on new tab")

  • From: Clemens <clemens.zeidler@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 06 Mar 2013 09:07:02 +1300

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 is
good, the other one is useless/annoying..."

You can do this as an extra decorator, without branching at all. Just the
same way Stack and Tile was developed. Or you can do it in your own branch
and 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 some
testing 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 good
way 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 included
in the image.
- Developers stay focused towards the R1 goal. Even if sometimes it's fun
or motivating to work on newer features, it's important to keep an eye on
the release target. And there are a lot of bugs we should fix before R1 can
happen

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 (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

Regards,
        Clemens

Other related posts: