[haiku] Re: R1/beta1: Here We Go (at last)

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Fri, 24 Aug 2018 08:35:34 +0200

On Thu, Aug 23, 2018 at 09:38:45PM -0400, DCatt wrote:

I have over the years thought about what it would take to get a more
official QA presence established for the Haiku project, but I think I
struggle with how it would fit into the scheme of things.  It would
obviously have to not get in the way so-to-speak.  I think the hardest part
is how would QA fit into the overall process.  QA folks usually like to
formulate test cycles for planned releases, providing feedback to the
developers in hopes to get nasty show-stopping bugs fixed and eventually
sign off something worth shipping to production.  However, maybe that's not
the way you do it with the Haiku project.  QA could be more transparent and
maybe just sample nightly builds on a scheduled interval and treat them as
unofficial RCs and perform regression testing to validate the reliable state
of Haiku and report back to the developers and let them decide what is
shippable concerning a more official release.

As a developer, I value QA a lot and I think you should, indeed, get in
the way. Don't be so shy :)

If you think we need a few more weeks to get the release through QA,
just say so and get things running. The developers job kind of stops at
providing nightly builds. We are a bit clueless about what happens then
and what makes the difference between a nightly and a release (well, I
do see it, but the constant pressure for "let's just tag random nighly
as betas" from devs and users shows me not everyone is aware).

So, it's up to you as the current QA team (yes, it is a small team yet,
but I think a few people are ready to help), to set up your
requirements. How much time do you need to test a release? Can you
involve developers and users in the process? Do you need any specific

We have not done any real release yet (just alphas and betas). The betas
would be a great time for experimenting with QA, I'd say. We can start
with beta1, or, if there is too much things to setup and it would delay
by several months or so, instead prepare this for beta2.


Other related posts: