[haiku-development] Re: Pre-proposal: Roadmap to Haiku R1 Release
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 14 Sep 2020 16:59:52 +0000
The timeline is not set in stone IMO. I share the concerns and I really do
think that if we need
to, we can reschedule. I just set this date because of my previous essay
around releasing R1 this
year. I'm okay with doing it next year if there is a sensible schedule behind
it.
Ok, in that case it seems better to plan for a break around christmas and aim
for a release a bit later.
I would, however, argue that it should not go on too long. I think focusing
on polishing a release
asks a lot of devs, especially when they are (also) working on projects that
are important to them.
Keeping the time period short should increase the odds that they are willing
to lay their pret
projects aside. (Caveat: did not ask around about this one)
Well I can give my vision of it. I have my own side projects (some Haiku
related, some not), but I
think I can manage myself and handle the priorities. Lately I've been more on
the Haiku side with
the beta2 release and then with GSoC, but I haven't stopped with the end of
GSoC, now I'm trying to get
our list of pending patches on Gerrit down a bit (and hope it will allow
improving the motivation of
other people whose patches have been stuck in review for too long).
My main concern is that it does take time to gather feedback after a release
(beta or not). People
will be trying it and writing reviews, report more bugs, etc. We need some time
to handle this input
and, even if we focus the developers on it, part of that time will be
incompressible. If the releases
are too close to each other, we won't have time to gather the feedback, so
there's little point in
making beta and RC versions. Your argument is also valid and we should not make
it too long. I think a
month or two between releases would be a minimum (at least between the beta and
the RC, I hope for the
RC we can make the time shorter as there should be less changes).
My initial gut instinct is that "if it is not ready, don't include it".
Yes, but that means keeping the old code and needing to maintain it for some
time.
The cost/benefit balance is then less simple. Maybe new, not very well tested
but better designed code
is better than old code with known design problems and bugs that can't be fixed
without changing the API.
In this particular case it's not about adding a new feature, but replacing a
part of the code.
My secondary idea is that
for these experimental APIs that we do want to give some exposure, we could
discuss the option of
shipping it as a static library in a separate development package so that end
users can pull it in
their build dependencies if they want to use it.
That's an option, yes.
Like I stated in the beginning, I am not married to the time frames. I do
want to emphasise that
the steps in the proposal have some thought behind it:
- A beta release to allow the public to test the most recent added
features.This should result in
tickets on dev.haiku-os.org, which we can then use to determine if they are
ready for production.
If not, we either have to fix them, but I am not impartial to the idea of
just deferring them to
the R1.x release proposed above.
- For me, no features should go into a final release if they have not been
tested in a beta
release. I am biased against releasing R1 sooner than later, so that's why I
am not in favor of
planning a beta 4 or even keeping the door to it open right now: if it is not
ready for beta 3, it
is not ready for R1.
I think there are not that many features in development or planned at the
moment. We are indeed in
a time of fixing bugs and polishing things out. The problem is, we have a
rather large backlog of
bugs, and we have to decide when we are "good enough".
Some of the reviews for beta2 (in particular the one from Ars Technica) as well
as the multiple
calls for help on the forum have shown aspects where we clearly aren't: the
install process,
the web browser, and to a lesser extent the eMMC disk support (but this one I'm
fine with pushing
to a later release). I think it is worth taking the time to work on these, even
if it delays the
next release by a few months. Our effort in these areas will be noticed more
than anything else,
or our lack of efforts would be noticed just as well.
I think such tickets deserve to be blockers even if currently no one plans to
work on them (and
the next step is of course to solve that and define a plan).
- There are some tickets I'd consider R1 blockers (#15728, #16304 and
#7930 at least). The last two I could consider moving to R1.1, but I
think not the first one.
Implied in my thinking is that we use the looming deadline as a way to
prioritize these issues, and
I am comfortable with the idea that there are `blockers` that will need to be
dealt with before
releasing. I felt that that worked well in beta 2, but I might be biased
because I am in the middle
of it.
I think in general there is already a good discipline on not adding tickets to
the R1 and beta3
milestones on Trac without careful consideration (and when there isn't, I go
over the tickets from
time to time to move them around if needed). However most of the tickets in
beta3 currently are
leftovers from beta2 (intel driver problems). I may have a look at them again
but for me it isn't the
highest priority at the moment.
So my summary:
- R1.x planned in a reasonable timeframe (6-12 months) as a follow up, and to
give a clear path for
everything that might not make R1
Yes.
- Very strong preference for the beta 3 - > rc workflow (and not with an
additional beta 4)
I'd make a final decision on this after feedback from beta3. Just like beta2
told us something about
the install/drivesetup process needing more attention than we thought, beta3
might come with a similar
feedback in a different area that would deserve our attention.
So, yes, RC if we can, but keep in mind we may hit something like that.
- Date proposals are not meant to be final, so they can shift. Additionally,
no release will go out
with blockers, so this is not a fundamentalist time based release proposal.
Fine, but I'd still preventively shift them a bit because there's christmas in
the way and because the
planned spacing between releases seems a bit short to me.
--
Adrien.
Other related posts:
