[haiku-development] Re: [haiku] Re: Future releases? Recommend nightlies? gcc2?
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 06 Dec 2016 14:57:45 +0000
6 décembre 2016 15:37 "kallisti5" <kallisti5@xxxxxxxxxxx> a écrit:
On 2016-12-06 00:10, Humdinger wrote:
On 6 December 2016 at 00:40, kallisti5 <kallisti5@xxxxxxxxxxx> wrote:
What if I make a poll on discuss.haiku-os.org of the most popular >> ideas
and
we go with "whatever has the most votes"?
[...]
Sound like a good plan?
No, it doesn't.
Contrary to what some keep saying, Haiku is not a community driven
project, but a developer driven one. That is, the people that are
doing the actual work get to vote on the direction. Sure, the user
community can be asked for their opinion to make informed decisions,
but I don't think this topic is well suited for that.
ABI/API compatibility is a difficult issue and many developers
apparently have a hard time grasping all implications completely. I
definitely don't. Going by uninformed popular opinion won't help.
All fair points. Then we need to as developers "nominate" those we agree
should hold decision making power. Currently we do things by shotgun
consensus without knowing what and whom to wait on a +1 from.
These are all likely reasons why the major things rarely get done.
It is not. The reason major things rarely get done is that we don't have much
time.
As Ingo pointed out last time this was discussed, the decision eventually is in
the
hands of people actually implementing the solution anyway. The most striking
example
is that the devs voted to use Mercurial when we wanted to move away from SVN,
yet
eventually git was used.
Voting or discussing does not get anything done. The more people you involve,
the
more you will get long discussions and bikeshedding.
The consensus part works rather well. We use it for granting commit access for
example. The process is well defined:
- One of the devs asks a yes/no question ("anyone against X getting commit
access?")
- We wait for 15 days for any objections
- If everyone agrees, the concensus is reached and the commit access is granted.
For technical decisions, however, there will always be people with a -1 or just
"I'm not sure" vote. So, we try to avoid votes in that case. Either there is
strong
concensus in one way or another, or the people who actually write the code get
to
decide.
I generally go to "community input" because I've been given no other
guidance on making major decisions. Since the community responds a
lot more than developers sometimes (no fault, but it's true) if I
don't engage with the community and try to appease them I end up
looking like a bossy a**hole.
Community input is fine, if you are interested in "what do they think"? But
giving the power to the "community" (read: anyone who sees the poll) is going
to harm the project ultimately. You can end up with decisions that the devs
disagree with, and the devs will just leave. Don't expect them to work for free
on implementing something they don't agree with.
What we can do is let people raise their concerns (as they did in this thread).
What we have gathered:
- Some people think we should go 64-bit only and legacy-free, to attract new
devs who run away screaming when they hear of gcc2,
- Some people think we must keep GoBe Productive running at all costs,
- Some people are still using 32-bit only machines and plan to continue doing
so for the next 5 years.
As you see there are some irreconciliable points of view here.
I (we) just want a release :-(
Just *do* it. Enough talk!
If people don't like the release plan, they can submit a counter-proposal. It
has to come with a candidate release manager and a draft timeline. In that
case, we could have a vote between the two plans.
--
Adrien.
Other related posts:
