[haiku-development] Re: The next release
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 08 Apr 2015 13:07:04 +0000
8 avril 2015 14:14 "Richie Nyhus-Smith" <richienyhus@xxxxxxxxx> a écrit:
The idea was, and still is, to have a beta release "when it's ready", as
defined by the tickets
put into that milestone, and from then on, keep a release branch from which
R1 will be made, and a
development branch for other developments. The time estimates were a bit too
optimistic, but that
does not change this plan.
That is a fine plan for a beta release, but that release is quite clearly not
going to happen for
some time with the current circumstances.
If you read my plan carefully, there is not any date set in it. So, it will
happen eventually. I don't know when, but it will.
There are some major problems and regressions in the current codebase (for
example WebPositive
has a lot of bugs that weren't in alpha4, USB has some regressions (they are
being worked on), and
our network drivers are a lot out of date),
<snip>
In other words, which tickets from the beta1 list do you think we cqn remove
for an alpha5?
https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=reopened&status=new&group=s
atus&milestone=R1%2Fbeta1
It deppens on your definition of alpha and beta software and your rationale
for publicly releasing
the software at that stage. That is, what you want in return.
I see the point of an alpha phase as getting early feed back from a much
wider spectrum of users
than what can be provided by devopers and other stakeholders. Plus it is core
to following the
paradigm of "Release early. Release often. And listen to your customers".
However you wouldn't want
to release regressions or bugs/issues that may result in data loss or
hardware damage.
After a quick glance at the issue list, we have at least 2 data corruption bugs
in hard disk stuff, and a bug about cpu idle not always working on some
machines (with the potential risk of overheating the machine and damaging it).
I don't think we ever adopted "release early, release often". This is Linux's
(the kernel) way of handling things. (unless I missed a change in policy at
some point).
I see the beta phase as being more about implementing a rigorous quality
assurance programme on
feature complete software and getting inquisitive end users to use it for
their normal purposes in
order to tease out hidden issues.
Our definitions in the Haiku project are:
* Alpha release: self-hosting (must be able to compile itself), no known
data-destroying bugs.
* Beta release: all criterions for alpha + must have all the features planned
in the next stable release
* Stable release: the project is done.
We probably need to change our definition of a stable release. But I think the
two other definitions are reasonable and don't need to be changed.
Therefore it would be easier to say what tickets I think should be kept, than
what I think should
be removed for an alpha release. Thus I can't see the connection between out
dated network drivers
issue and an Issue would block a theoretical alpha release.
Our goal with previous release was to test wathers with new features, and
collect bugreports on those. People testing these versions were a bit
adventurous and knew they risked data loss, or any kind of bugs and stability
problems.
Yet, a lot of effort went into making the releases as stable as possible, so
they would be useable in a test environment. This way, people could actually
run them and find more subtle bugs and problems.
This is the reason for doing alpha releases from the developer point of view:
to have a bigger public exposure on some new features in order to collect as
much bugreports as possible.
we still don't have the infrastructure for doing a proper release in terms
of packages and
repositories. This is what is really blocking beta1, and it would block an
alpha5 release the same
way.
Without this solved, you may as well pick a random nightly and call it
"release". But we won't be
able to offer the required level of support for it.
Or in other words, ticket #10893 would not be fixed, as in the status quo.
Something that
definitely needs to be fixed before a beta, but would be acceptable in alpha
software.
Yes, an alpha at this stage would be much like the "Discover Haiku" endeavour
released by Dane &
Co, only with more quality assurance and with the regressions and data loss
bugs fixed, but that
wouldn't be too dissimilar to the state that alpha1 was in. Plus it would
show outsiders that the
project is alive through action, rather than just talk (which does work; but
only so much).
You are planning a release in terms of PR rather than development (which I
think was the main focus for the previous releases as I highlighted above). So,
let's look at the current state of Haiku from the user's perspective. We would
sure give a "sign of life" with a new release, but:
* Our support for network devices is not that good, most machines released
recently won't have network access
* Our USB3 support is missing, so on machines with no USB2, you can't even boot
the system
* Even if you manage to boot the system, you get a repository of possibly not
installable or broken packages, and a lot of missing packages (despite having
recipes for them)
* If your disk is above 250GB, you will probably corrupt it if you try to
create an Haiku partition
* Even if you get past all that, you get a mouse that freezes for almost a
second, and a web browser that crashes on the first occasion.
This is not a sign of good health, even if it is a sign of life. I would rather
avoid a rushed release resulting in that, and, first and before planning
anything, see how these issues can be solved.
Note that I included in this list the fact that our package repo is incomplete
and inconsistent, which is also the main blocker for beta1. I don't know how
much time is needed to complete this, but it is not particularly related to
"the current circumstances" as you say (development on this is slow and has
seen little interest from the devs, current circumstances or not).
Even if we remove this, the other issues will have to be solved before we
consider a release. Since it is not the same people working on them anyway (as
I said, most of the haiku devs aren't much interested in contributing to the
package buildsystem), why not do both? If it turns out the package system is
taking more time than solving the other issues, it will still be time to
consider tagging the release "alpha" and removing that particular item from it.
So is Haikeuken going to be officially adopted by the project or is it going
to remain a 3rd party
project by Alexander? Does the project still need to recruit a volunteer to
assist Alexander with
development or is something else happening?
What do you need to make it "official"? kallisti5 is a member of the project,
with commit access, so this IS already part of the Haiku project. When it is
ready (or another solution is, I don't mind personally) we'll start using it.
We could move it to a server with hosting paid byy Haiku, inc. but that doesn't
make it more "official" as far as the Haiku project goes.
As for recruiting people, the decision is in Haiku, inc. hands. They would
probably accept it if someone offered help on this at a reasonable price. But I
don't know of anyone interested in doing the work.
--
Adrien.
Other related posts:
