As Jeff Atwood once wrote, listen to your community, but don’t let them tell you what to do: Listen to Your Community, But Don't Let Them Tell You What to Do.
People will request more things all the time, it’s then a duty of the core team (being it Haiku or any other project) to have a vision of the project development, and to turn down requests not aligned with that vision. IMHO Haiku development would benefit greatly from having a BDFL, like many other successful open-source projects do. So, there will be always one person who has a final say in a discussion with opposing views.
On the constructive note, I’d gladly offer help to walk through those 600 tickets with someone from the development team, and ruthlessly move some of the tickets out of R1
Haiku benefits much more from people discussing these things and reaching a common agreement, or a compromise if no agreement is possible, than from one person having the right to say “I’m the dictator, I’m the one who makes the choice”.
It also allows people to leave the project without putting it in danger. A lot of the initial developers have “retired” or are not as active as they used to be. They may come back someday, but until then, other people have taken up the work.
…not seldom it’s also “let’s not do/change anything because some people disagree”.
I don’t see how those two things are connected. There’re projects whose BDFL had stepped down from the role, and it didn’t put the project in danger (e.g. Python and Guido van Rossum).
I’m not going to convince the Haiku development team to switch the way the project is developed, as you folks seem to be quite happy with the current Haiku way, so who am I to suggest to change it? Personally I think the way certainly has its pros, but it also drags the project down in terms of the speed, and is one of the reasons why after more than 20 years of development the version 1.0 isn’t on the horizon yet. But that’s just my opinion.
Not really. The reason version 1.0 is not released yet is because we have set ambitious goals and decided to keep these goals (or, in a few occasions, extend them). A single person could have decided to do that as well. For example, if I was the person in charge, I would probably not be so interested in making 1.0 happen. (you may say, then, that is is a good thing I am not the person in charge).
Releasing a version 1.0 is just not that important for us. A lot of the people contributing to the project are there for the journey, rather than the destination. And so it’s not at all a problem to take a few detours along the way.
It is a good thing you are not the person in charge, here you are
Nothing wrong with that, but then it probably should be mentioned in the FAQ as the team’s philosophy. Because apparently it’s important to at least some part of the community, as the discussions about R1 keep popping up now and then. (I’d also say it’s important for marketing purposes and Haiku perception by the external audience, but that’s another topic, big and complex one).
How does the process usually look like after the new beta is released? Currently, there are 13 tickets for beta6, and exactly 600 for R1. Will you and other devs grab some of the R1 tickets you feel like the right ones to be implemented/fixed for the next release and bring them to beta6 milestone, or use some other strategy?
Also, do you have any statistics on how the number of R1 issues changes from year to year? Is it decreasing or increasing, and at which pace?
I think lately the tickets have been moved mostly as they are fixed. This is because there is no real priorization for betas: everything that is in the R1 milestone should be done in some release prior to that. There may be more priorization after R1 (for R1.1 or for R2), maybe, or it may continue in a similar way.
Sometimes people try to move things into the next upcoming beta, but if they don’t actually plan to work on it, it just ends up being moved to the next release again and again as no progress is made on it.
I don’t think Trac allows to easily gets statistics on the number of tickets in each milestone. Maybe the only way is finding previous discussions where people mention the number of tickets in the R1 milestone, or maybe check out the web archive. Which gives us:
2024: 600 tickets
2023: 627 tickets
2022: 638 tickets
2021: 661 tickets
2020: 1058 tickets (the R1.1 milestone did not exist yet, so a lot of tickets were moved out of R1, but not solved)
2019: 1211 tickets
2018: the page was not archived in the wayback machine
2017: 1991 tickets
2016: 2093 tickets
2015: 2183 tickets
So, since 2020, that’s 61 tickets less in 4 years. At this rate it would take 40 more years to complete R1. Maybe this metric isn’t the best one The good news is it’s consistently decreasing year-over-year.
It’s not really that no tickets gets solved (indeed we have solved 350 between beta 4 and beta 5), it’s that new ones keep getting created at almost the same rate. But that’s a bit more complicated to measure with just webarchive. A custom Trac plugin could do it, maybe.
Maybe there will be someone, but I think the overall rush over the R2 release will be much less than over the R1. Psychologically, the leap from 0.x to 1 is far bigger, then from 1 to 2.
I remember those days… At some point in those years, I started just going through the R1 milestone and triaging the old tickets in there, which resulted in a lot getting moved to Unscheduled, stale ones getting closed, duplicates getting merged, etc. There were some others doing the same, of course, but I definitely have spent long periods staring at ticket lists and seeing what can be done about them…
The TicketStatsPlugin used to do this, but I think we had do disable it when upgrading Trac. No idea if the upstream was updated to support the newer Trac versions (it doesn’t appear to have been.)
