[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 23:14:04 +0100
Hi Adrien,
I'm going to split up the response into two parts, this one is some context
about the proposal to work with owners.
On Thu, Sep 24, 2020 at 11:30 AM Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:
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.
This is already more or less the case in Trac: assigning a ticket to a
component results in assigning
it to the appropriate developer. Some components are assigned to
developers who are currently not
active.
This used to be more formalized, but that was lifted as it resulted in
some friction for cross-component
work. To take an example, work on WebKit problems led to improvements in
app_server, kernel bugs
(misaligned stack preventing use of SSE2 instructions), media kit, etc.
Being able to work on multiple
components at the same time is one of the strenghts of Haiku, compared to
the way it's handled in Linux
distros.
The idea for owners/maintainers is really within the context of
responsibility for determining the status of the individual parts of the
code base to see how far we are off from R1. Maintainership or ownership
is not meant to exclude the open development model we have right now.
Maintainers/owners are not ultimate gatekeepers. It also does not bind
owners and maintainers to exclusively work on their components.
The main line of argumentation against committing to a timeline for a final
release is that the work is not ready and therefore we should watch the
tickets. I really appreciate the effort you have put in your triaging, but
with about 695 + 30 tickets to go, it is too much for one man. The other
extreme, ticket status meetings like we organized for beta 2, are also not
scalable to that level. We spent the hour looking at 5 tickets, so that's
another 125 hours to go. I know that I am taking the extremes here, but
reality is that R1 will be in the same limbo as it was before.
Moving to the maintainer model will decentralize the responsibilities of
triaging. Now granted, for this to be a success we would need a fair number
of owners step up, there currently are 305 components in Trac. Not everyone
needs a unique owner, but there are some parts with the most work cut out
for them (I'd count intel extreme, core libraries, system
installation/upgrading and webkit/webpositive) that could use a dedicated
owner (or dedicated owners) familiar on the terrain. Likewise, there are
components that haven't been touched in a decade (probably when i18n was
introduced), which could use a junior contributor or a non-dev contributor
to review the tickets and sign it off for R1.
Regards,
N>
Other related posts:
