Disappointed with Haiku


#163

Just a thing I wanted to clarify. The user guide translator and other similar tools have started as side-projects and were not really part of Haiku at first. A few years ago it was quite a mess with svn and mercurial and github repos everywhere.

The sysadmin team is hard at work streamlining these things. Everything has been migrated away from SVN and mercurial, and now all repos are hosted in two places: the haiku organization at github, and our own Gerrit server. I hope someday everything will be on the Gerrit server, but not everyone will agree with this, for now.

So, yes, it is unfortunate that you landed in one of the wild and unexplored parts of the Haiku project codebases. I think people working on the C++ code would have less trouble than you did. We definitely should improve this. I think however that this is also one way you can contribute. Now that the website is also hosted on github, it is easy for anyone to improve the contributing guides and make these things more welcoming. And it is actually much easier to do so from an outsider perspective. People who are in the project for a too long time will simply grow tolerant to the issues.


#164

FWIW, I don’t get this feeling from @kneekoo at all.
I think he correctly pointed out some inadequacies in our documentation. Where I think he takes a wrong turn is, that he expects the current devs to correct this immediately. The hard truth is, that the project is fantastically understaffed and people work on things that are a) more important or b) more fun.
Or in case of the user guide translation tool, we just have the code by someone not longer around. Ironically, with his PHP expertise, he might be the best qualified to work on its docs and the code…

Looks to me like one person fixed the underlying problem and another closed the ticket. That your contribution in spotting the error and triggering the correct fix wasn’t mentioned was a bit unfortunate and people should add a “Thank you” when closing the ticket (the comment itself was correct, the patched wasn’t needed anymore).
@waddlesplash is normally a polite fellow, so it might just be that he was in a hurry or distracted.


#165

That’s fair. I scanned over the thread again (jeeze this thread is getting long) and I overstated things a bit and mixed up a few peoples comments.

It’s easy to say people should do something, it’s harder to actually do something. When only a handful of people are working towards an endless work queue for a hobby, nothing is more frustrating and demoralizing than having people dump in demands and non-constructive feedback.

I stand by my “grab a hammer” comment.


#166

No, the ticket was closed on 31 Jul. I committed a fix independently on 26.Aug. How would I know something about a closed ticket? Mystery.


#167

So it didn’t work back then on Jul 30. The PR was closed Jul 31, because it did work without it, as confirmed by kneekoo on Aug 1, mentioning some backend fixes. Nevertheless you fixed it on Aug 26?
It’s like an Escher painting… Hmm, maybe I don’t actually want to know the details here, but just enjoy the contradiction.


#168

For me more incoherent is what kneekoo wrote: “someone fixed it and didn’t even care to mention it on GitHub, so the conclusion was “Closing as not-needed, then.””


#169

Here’s a timeline:
30 July: I submitted a pull request to fix a broken link;
30 or 31 July: Someone apparently fixed the link directly on the server, bypassing GitHub;
31 July: @PulkoMandy noticed the link worked, @kallisti5 agreed, and so did @waddlesplash - who closed the PR as no longer needed;
26 August: You fixed the exact broken link that I had fixed weeks before and your PR was approved;
8 September: I got curious about that file and I checked who fixed it. However, I didn’t even think about checking the date of your commit and I assumed you were the one who fixed it on 30-31 July as a result of my PR.

What is incoherent is what’s going on behind the doors. So far no one stepped up to say “I fixed that”. And it is mind boggling that 27 days later you changed the same broken link. This means:

  1. Someone fixed it “by hand” on the server;
  2. An automated process pulled the code from GitHub and “broke” the link again;
  3. Weeks later, you fixed it by submitting a GitHub PR (the right way).

So I wonder, if you guys know your way around so well, why did anyone bother to manually edit the file on the server if their contents get automatically overwritten by git syncs? Just because the link I proposed wasn’t the one currently used? Then why didn’t someone say “wait, this other link is the right one” in my PR, close it and properly fix the link in the first place?


#170

I don’t remember what was going on then and since Adrien and Alex had already chimed in I just went with what they decided and didn’t look very closely as to what was going on. @korli’s fix is clearly the correct one.

The www domain is served from a global CDN which deploys using the build_for_deploy script in the scripts directory. That’s it, there’s no magic; we don’t have any access to the CDN besides pushing new states to it, and IIRC I have it locked so that it deploys from GitHub only (there is somehow a manual deploy process but I have no idea what it is.) So, no, nobody fixed it “by hand”, as that is actually impossible


My guess as to what really happened is this: The original pre-fix link was relative, i.e., it points to a file in the present directory. If the URL had a trailing slash (it appears to have as much when linked from the homepage), then the link worked. If it did not, the link hit a 404. Somehow, @kneekoo wound up visiting a link without a trailing slash while @pulkomandy and @kallisti5 visited it with one, so it worked for them, and thus the PR was closed. Somehow @korli hit the same bug and fixed it correctly.

That’s the only way by which nobody involved is wrong in that it worked or was broken for them, and also nobody “fixed” it on the server as that is impossible.


#171

Well, I didn’t manually enter URLs. I clicked the big Get Haiku button on the front page, then I clicked the R1, Alpha 4.1 link. If everyone else did the same, then the code under the hood seems to be buggy. Because the only way we could end up with a 404 was if the Get Haiku button is sometimes offered without a trailing slash on the front page.


#172

But there is a notice that the alpha 4.1 is not the current state and people need to take a nightly build.

Get Haiku!
While we work on the last few blockers before R1 Beta 1, it is strongly recommended you try out a nightly/development build.

The Anyboot image is the preferred distribution format. It can be written directly to a USB flash drive, empty disk, or written to CD/DVD media. It can also be used directly from various emulators such as QEMU, VirtualBox, VMWare, etc.

Previous Releases
Version Date
R1, Alpha 4.1 November 14th, 2012
R1, Alpha 3 June 20th, 2011
R1, Alpha 2 May 10th, 2010
R1, Alpha 1 September 14th, 2009


#173

As a developer I need to be able to check whether a bug is a regression compared with another release. I needed to download the alpha4 end of August for this reason.