[haiku-development] Re: Update on Haiku R1 Release Proposal
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 24 Sep 2020 09:09:36 +0000
Well, some stuff just got important in the last ten years that weren't
before, like HiDPI, USB3, NVMe, etc.
We do support these now, even they weren't part of the original plan.
And as long as we have developers that don't keep sitting on ancient
hardware forever, this will happen in the future, as well.
Sure, they should maybe not hold up the release, but we could also not
ignore USB4 if we need another 5 years more for R1.
So I think Niels is not wrong here, even though one doesn't need to
change plans, the desire to do so will certainly grow over time.
Yes, but still I think these things don't need to be in the R1 roadmap.
Sure, if they happen, we can integrate them. If they don't, we can ship
what we have, and maybe someone will provide a 3rd-party driver for them
(ok, for hiDPI, it's more involved, but for the other parts of hardware
support, that's possible).
In the 2010 poll, we had 3 options for each feature:
- We should not do it
- We sould do it
- We should include it if it's ready, but not delay the release to work on it
I think hardware support should be in the 3rd category. It will happen
anyway because of developers using Haiku on their own hardware, and it
is important for the project as a whole, but not for R1 itself.
In terms of features, we are already there (in fact we are past it).
To me the work currently needed is: - On fixing bugs - On finetuning
our release process: how to manage maintenance updates, how often to
do point releases, etc.
That's all. No new features, pleases. Even with a longer term plan to
fix all bugs I think it is unreasonable to add new features to the R1
target at this point. With such a short timeline, even less so.
That sounds reasonable, but with the caveat from above, it may only work
over a relatively short time span, like 12 to 24 months.
I'm thinking only in terms of defining the roadmap for R1 here, and general
focus on getting it released. I think we can't prevent anyone to work on
other things anyway.
In terms of "what do we need to get R1 out", at this point, I'd say it's
mainly bugfixes. In terms of "keeping the project relevant and usable",
there is a lot more.
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.
Most of them are tickets that were scheduled in beta2 and postponed to beta3.
A good sign that they are probably not all that important. I think we didn't
have any discussion on the goals for beta3 so far (for me it was clear that
the main goal is "fixing more bugs"). We have added some tickets from feedback
on beta2, these are mainly:
- An app_server crash when using youtube (preventing tunetracker to use beta2,
and generally annoying)
- Improvement of the installation/drivesetup process (several users had
problems with that, including an ArsTechnica reviewer)
Indeed fixing these will hopefully not be too much work.
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.
I already moved 360 of the 1000+ tickets to an R1.1 milestone (from my own
opinion on what's really
required, if anyone disagrees, feel free to move them back, or move more things
out). So, yes, if we
want R1 to happen soon, we have to take the time to review this list and decide
what we really need
in R1, and what we can afford to delay a bit more to an R1.1 (which I expect
would happen as the next
release after R1, 6-12 months after it) or later. And maybe we can then reduce
the list enough to
actually have plans for R1 in a short term.
--
Adrien.
Other related posts:
