[haiku-development] Re: Busted!

Michael Lotz wrote:
I'm using a patched version (to fix the first error) and stuck at r30825 until these issues are resolved. But the conclusion is that the build (meaning complete cycle of build/install/test) has been broken for 8 days unless you have the time and inclination - and believe me, I won't have the latter much longer - to fix it. 

I am sorry to tell you, but I am unable to reproduce any of the issues you
mention. I have a clean tree at r30866 and did a clean build of the haiku-cd
target to investigate, but it boots just fine. Maybe you can attach your
UserBuildConfig to one of the tickets to see if a configuration option
triggers it.
By r30866 it's likely that these issues had been resolved, thanks to my alertness in reporting them. Try updating to r30830 and see if you can make an installable CD. 


That is a way of looking at it. The point is that after a release, which one
remains to be decided (R1, alphas or betas), the development model will be
adjusted to not do main development directly in the trunk anymore. Branches
will most likely be used. But we are simply not quite there yet. Discussions
have been held about this. If you want to restart them, you should dig them
out of the archives, summarize them and start a new discussion based on them.
Or reply to one of the already open ones.
The problem is that developers aren't testing code properly before committing it. That won't ever change by itself. 


Then we might all get some work done.


You always make it look like everyone was deliberately putting stones on your
way. But please decided what you want. Either you want to get your personal
work done, the TV driver I take it, then you should follow the suggestion to
simply not update so often. Or you want to move Haiku itself forward, which
means identifying and fixing bugs and regressions.
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.
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.
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.
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. 

Rob

Other related posts: