[haiku-development] Re: Busted!

On Sun, May 31, 2009 at 3:39 PM, Rob Judd <haiqu@xxxxxxxxxx> wrote:
>
> The problem is that developers aren't testing code properly before
> committing it. That won't ever change by itself.

Haiku developers definitely test their changes. They certainly try to
make sure the build is not broken (in our terminology, in other words
everything compiles) and that the code complies with the coding
guidelines. But there may be some changes that cause problems for
existing installations. Like changing directory structures or some
kernel changes. This stuff must happen for development to continue and
improvements to be made in an OS that is currently IN DEVELOPMENT.
There is no guarantee that existing installations will not be broken.

> As I already pointed out, I'm updating regularly in the hope of finding a
> more stable version, so not updating isn't an option. The TV driver is the
> least of my concerns, I have about 10 other projects on hold.

I know we have said it 100 times, but whatever you can do to isolate
the sources of your instability will help you and everyone else who
wants to use Haiku. Maybe it is driver issues, or something more core
in the OS, but any help from your side will speed up any fixes. Other
developers certainly are trying to improve stability, but they may
never randomly fix the problems you are having, unless it is something
they happen to find themselves.

> Yes, I could continue to identify bugs, but for every one I find there are
> several more being added to the code base. A more recent example was in the
> addition of two symlinks to /boot/develop/lib/x86 and
> /boot/develop/headers/cpp which conflict with existing directories and cause
> an update install to fail. This was reported at r30914 and wasn't resolved
> at last check.

This is not a bug and was added for a definite and useful purpose (the
use of multiple compilers), so you just need to deal with such
changes, as annoying as they might be. Haiku will and must progress,
and may change in ways that screw up your installation. These are not
patches to existing installations, these are changes to a developing
codebase that happens to be installable.

> The same change also clobbered the link at /boot/develop/tools/gnupro. This
> change shouldn't even be in the repository since that link is installed by
> the compiler. The point I'm making is that these issues should rarely
> happen, and wouldn't happen at all if the full installation is tested
> properly.

You need to realize that there just won't be massive efforts to
regression test until a release is made. There is no reason or
especially resources to have those now before there has even been one
official release of an alpha. Keep in mind you are running pre-alpha
code that is currently in development and therefore you have to accept
the associated risks. Plus I can give you the standard disclaimer of
NO WARRANTY and everything that is in all software, even released
stuff from big companies like Microsoft and Apple.

Further you classify as bugs things which others consider positive
useful changes.

> When multiple bugs begin to overlap, as they did between r30790 and r30851,
> then the task of untangling the mess becomes very time-consuming and
> difficult, and lands on everyone who downloads that version. It's a large
> part of a developer's job to understand the full ramifications of his code
> changes and predict possible consequences.

Certainly, but the kind of due diligence that will be required and
done after a release will not be done during development, especially
at this pre-alpha stage. Certainly when these "bugs" are really only
annoyances to Haiku installations.

Let me give you a metaphor: you are like someone who has downloaded a
pirated version of a pre-beta Windows, installed it and then complains
to Microsoft when things break. Please look at Haiku from that
perspective: the only reason you can install it is because the Haiku
developers need to be able to run and test it. It does not mean it is
released code that is 100% reliable and completely regression tested
on every change. If we could get to such a stage then great (such as
WebKit which has layout tests they run for each change.) But that
requires a lot of work, a lot of test code, and it just is not
something we can do with our resources at the moment, plus it really
doesn't make sense at this stage (WebKit is released software used in
several browsers and rendering regressions are a very big deal.) Haiku
is not yet released software.

Regards,
Ryan

Other related posts: