[haiku-development] Re: Update on Haiku R1 Release Proposal
- From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
- To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
- Date: Thu, 24 Sep 2020 10:57:48 +0100
Hi!
On Thu, Sep 24, 2020 at 8:41 AM Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
Any proposal on a date and plan for shipping the release probably
won't change my mind on this, because it doesn't attack the main
issue: we just have a lot of quite annoying bugs to solve or at least
review. And once we have done that we can have a rough idea how long
it would take to go through them, and then ship a release.
I just looked, and there are 29 open tickets for beta/3 -- I haven't
really looked into the effort required to tackle them, but the number of
tickets seems to be okay.
For R1, however, there are still 695 open tickets (610 of which are
bugs). It does not sound likely to me, that we will be able to fix them
all in a reasonable timeframe. Even if we'd close one every day, we'd be
working on this for the next two years.
I think we should try this, but rather generously move tickets to a
later release -- even if this means more discussions, and taking time
off from development.
A possible way to tackle the issue of how to do ticket triaging, is to
select maintainers/owners for parts of the code base. Their role would then
be to triage tickets and the state of their component. They then will be
able to communicate readiness to the rest of the community. They would also
play a role in triaging the existing patches on Gerrit.
An additional advantage is that this offers a path into more responsibility
in the project for some of the new contributors.
But in general, I tend to agree with Adrien, that we should focus on
tickets, not a fixed timeline
For me, the goal of setting a timeline is so that there is a clear
organizing principle on how to decide 'should this be in R1, or can it
wait'. Having a clear timeline will also help prioritize questions like
'should I work on feature X, or will I deliver more value to the community
by working on issues A, B and C'. The timeline in my proposal is never
meant to be absolute, there are checks and balances in there that allow
extending the timeline.
The reason to focus on a timeline for R1 rather than for R1/beta3, is that
I think the user and 3rd party dev community is hindered by the lack of a
stable/final platform. I also personally believe that releasing R1 opens up
more exciting paths and opportunities for core developers, and I think that
this will help grow the developer base. That is just a hunch, I have no
real clear indications of that though.
In any case, maintainers, anyone?
N>
Other related posts: