[haiku-development] Re: The next release

  • From: kallisti5 <kallisti5@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 08 Apr 2015 07:50:21 -0500

On 2015-04-08 07:14, Richie Nyhus-Smith wrote:

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.

+1. We're at a stand-still.

Lets look at the ticket counts. I've been tracking the Beta 1 tickets weekly by hand
for the last 5 months as Trac doesn't make these numbers easy:

http://haiku.tips/release-burndown-chart/

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=status&milestone=R1%2Fbeta1
[1]

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.

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.

We need a release. We need one now. As a reminder we have made 0 releases
since implementing Package Management.

I think the priority issues atm are:

* WebPositive bug squashing and refinement.
- Invalid SSL certificates result in a notification for each reference on a page.
* Finish new NetworkManager (it's in the nightlies now, needs some refinement)
* Fix #11174, processor missing
* Define what packages will be part of the releases and rebuild them.
- Make an official list, then we know what packages need to be compiled fresh.
http://cgit.haiku-os.org/haiku/tree/build/jam/repositories/HaikuPorts/x86_gcc2
- This can't happen until we have a *solid* release date.
* Disable fstrim #10336
- This can only happen once the next release is branched.

Those are my top list. I think if those could completed we would be in good shape for
beta1 or alpha5. No it won't be perfect, but it will be a release we deeply need to
show off what Haiku can do.

One thought, if we branched Beta 1, would / should we keep all future Beta releases + Final
releases based on that branch? I personally would like to see Beta 1 *unless* we decide
that R1 should be based on the beta branch... then one more alpha makes sense.

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?

Help needed! I have 0 free time lately. I was in the process of moving
it to a new server but haven't had the time to stand it back up.

I'm still a lone man working on it :-)

https://github.com/kallisti5/haikeuken-client
Issues:
* Really need a working Ruby 2.2.0 port (I have one kind-of-working on my Haiku
box, it is still flakey though)

https://github.com/kallisti5/haikeuken
Issues:
* None really, it works and schedules builds of packages to the client
it also tracks broken recipe lints and outdated repo packages.

-- Alex

Other related posts: