This I can concur with. Haiku has suffered for YEARS… with “two steps forward, one step back” from developers stepping on each other’s toes. Everything is working in one revision, then a new revision comes along and something is broken! Wouldn’t it be great if EVERYONE was on the same page, development-wise? As an end-user… I have more or less totally given up on Haiku being stable! I’m afraid to update, because if I do, maybe networking will be broken again! Yeah, I get it… it’s beta… just like it was alpha and pre-alpha before that… but WHEN do we get to a point where updates are something we can look forward to and not fear? When can updates be expected to improve things without breaking things?
If what x512 is doing is not harming anything, but only adding to the beneficial function of, why is there so much push back? If Haiku was a company with a CEO… like Apple’s Steve Jobs, for example… yeah I get the whole “you do what I tell you, because I pay you.”, but as has been made abundantly clear in the past, Haiku is a free field, where you do what you want, when you want, how you want, for as long as you want… and EVENTUALLY it will reach R1.
Meanwhile, x512 may just happen to have a completed (R1?) version of Haiku for RiscV long before then, because he’s doing everything himself. “One man’s vision CAN make a difference.” Right now, I’m more interested in his RiscV port than anything else. Even if I had to buy a motherboard for $600… if I can use Haiku (RiscV) overall, for everything I do in Windows… gah! I could ditch my Windows systems! Wheee!
YES! Work TOGETHER! Stop arguing over things that are not actually harming the project! If someone can step forward as the true leader (CEO) of Haiku… THEN they can dictate how Haiku should evolve. But that wouln’t be very opensource, would it?
I concur here as well. What we each “believe” is right for Haiku, is individual. I argued ages ago, that Haiku was throwing the cart before the horse. Doing things in the wrong order. I still do, to a degree. But what corporation ever listens to the peons who buy their products… nope, THEY know best what WE want, don’t they? And so, Haiku has taken 20 YEARS to reach Beta 3. Seriously?!? How many versions of Windows, Linux (and other variants), MacOS X, etc. have passed by during this time? If developers got behind Haiku as a project for OTHERS (not just themselves), as BeOS was… I still concur we’d have seen R1 long ago and we’d now be in some other revision of R2, R3, or something. It wouldn’t matter if Haiku R1 only ran on older hardware and was really no better than BeOS R5… it would be a solid stake in the sand of time… “We REACHED R1!”. From that point, you can advance in any direction, without nay-sayers. Without people like me asking why it’s taken 20 YEARS to only get to beta 3.
At the rate x512 is going, I wouldn’t be surprised if we had a solid, usable version of Haiku running on RiscV before Haiku beta 4 (x86_64) is reached. And THAT kinda progress is what excites me!
Some people work better in collaboration within groups. Some people accomplish more on their own than a group can simply because they know what they are doing. The industry favors the former due to what I call “elitism”; more sheep to herd. The latter, sometimes called “cowboy coders” as a reference to the old radio and television series The Lone Ranger, accomplish what they set out to do just by knowing how and doing it.
When you get both kinds together, mayhem ensues. The cowboy coders chafe at the authoritarian elites cramping their style while the elitists look for ways to get the cowboy to wear, rather than ride in, a saddle. You can’t have it both ways. I’d prefer to stay out of people’s way but if authority is needed then it is time to see some moral behavior dominate and let the free spirits do their thing.
I would strongly suggest to stop attacking people like this. Criticism should be welcomed, even if it might be hard to accept. Somebody took the time to review your work, and that should always be something positive, even if that someone comes to a different conclusion.
No one is trying to take anything apart, and we all need to work on an atmosphere that creates valid discussions on code without anybody feeling bad. Of course, that goes both ways, but a -2 should always be possible without hurting anyone. It really just means “I don’t want this merged like this”. It’s the start of a discussion, not a final ruling - no one has this power.
That view I can support. There is no harm in accepting that code for now. I expect that it will be removed some day, as it has limited use, and I also personally think that a generic boot loader is much more worthwhile spending your time on, but if that is where your passion is, I don’t see any reason to try to stop you, as, as you said, it doesn’t harm anything.
I am not convinced that adding an abstraction layer for drivers makes much sense in the boot loader, unless we want to have many machine specific boot loaders. However, if such a restructuring improves the code, instead of just making it more complex I certainly would not mind to have it in the tree.
As I said it is needed at least for FDT handling. FDT is used on many non-x86 architectures and platforms. Some devices like UART, CPUs or interrupt controller are needed to be detected at boot loader stage.
FDT handling is currently terribly duplicated and not arch-portable.
I was under the impression that we did not want to use the FDT anymore, if possible. But sure, there you do need it. But AFAIU FDT is its own platform, so it will be sufficient to add a driver layer there only, or at first, and if it proves to be needed elsewhere, the driver layer could be ported to the common loader code.
For example on HiFive Unmatched RISC-V board I currently using, static hardware, CPUs can be only enumerated by FDT. The same with most ARM devices. FDT is provided by built-in firmware.
FDT is not directly related to platform, it is used by EFI, u-boot and RAW boot loaders. Firmware do not provide all necessary API to enumerate required hardware (CPU cores for example).
Using FDT vs ACPI is decided by hardware manufacturer.
After reading @waddlesplash’s responses to criticism from others regarding his behavior, it makes it very clear to me that he cannot admit his faults. Even when he is clearly in the wrong, he will make up excuses. I’ve said it before; he is a masterful manipulator.
I have stated that I appreciate his knowledge and contribution to Haiku (with exceptions), but his conduct is not representative of what is to be expected of a developer with commit access. He acts as a team player when the consensus is in his favor, but takes executive decisions against the will of others when they are not.
I agree that he should be stripped of his privileges until he has can show that he has matured. I doubt that he ever will, but I would love to be proven wrong.
Once again the discussion is sliding into personal attacks and disagreements on non-technical grounds. This is annoying and not pleasant to see. Can both of you behave and not descend into a fist-fight?
X512, please note that waddlesplash is only one of many developers running the Haiku project. If you are not happy with the way he is behaving, you can start by discussing things privately with him by email or irc/matrix or whatever method you both find convenient. Itis not constructive to threaten to stop submitting your work, ask people to downvote tickets, or otherwise try to get the community as a whole to pick one side or the other. This divisive behavior does not earn you points here.
Waddlesplash, it is not the first time that you use your authority as a project member a bit too strongly in places where it is not appropriate. Things like giving -2 to patches despite other developers disagreeing with you (it’s not the first time you do this), and generally, I think, not being very open to new ideas. Clearly, some people in this thread (even ignoring the trolls: and people who are trying to stir up old problems which you have long grown up out of) are annoyed by this.
I don’t think this should go immediately into revoking commit access as some people have suggested. I hope that you both can take time to read back the various discussions, reflect on your own behavior, and see how and why this went into a fight instead of what should have been solved in a 10 minute discussion if you both had stayed on technical discussion and not other personal or behavioral things.
You are both good developers, please don’t put the Haiku project in a situation where we have to decide which one of you we should keep.
I’m curious… I assume there is a type of heirarchy within the Developer pool. Or is it simply a democratic process by which votes among the Developers would determine who gets what access to do whatever. x512 is obviously not granted the status of “Developer”, as you and WaddleSplash and Axeld, etc. are. But I suspect he has contributed enough and generated enough enthusiasm, that he holds just enough clout that it either threatens the perceived power structure within Haiku (hence the arguing) or has given him some unstated “sub-Developer” status or something.
Unless someone’s material is actively causing trouble within the source code tree (commits are breaking stuff… a lot), then I really think that both WaddleSplash AND x512 are two devs (one officially and the other… not yet) need to find a way to get along, for the sake of the whole project. Egos do NOT have a place, IN a place where such bickering could destroy the ENTIRE place! Savvy?
Commit access to the repository is granted to people who are trusted to have good understanding of:
Our coding style
The way we discuss things together and reach decisions in a peaceful way
The shared vision we have of what Haiku should be and the direction we should work on
This is granted through public proposals to the haiku-development mailing list after one of the existing commiters sends a proposal to add someone.
While X512 has done a lot of work so far, at least the first condition is not met, as patches consistently have several coding style problems, with apparently not a lot of motivation to go back on older commxts and fix the problems. There was also communication difficulties as they didn’t use IRC and mailing lists, which is one of the places where a lot of discussions happen. I think this latter part is now fixed, with the use of a Matrix bridge for IRC access.
As long as at least the coding style aspect is not resolved, the process will not go further.
Both of these problems resulted in some frustration for everyone. Communication issues result in misunderstanding. Code that does not follow the coding style requires a lot of work to clean up, and there is pressure on the commiters to get things merged when it blocks a big new feature like the risc-v pomt. Eventually we decided to merge the code anyway. Kallisti5 fixed several coding style problems in the platform-shared code, and the risc-v specific code is in a “we need to clean this up later” state.
This approach results in improvements in the short term (we get a risc-v port!) but it adds technical debt (code that we need to rework later). And people who do the clean up may introduce bugs (as with any change to the code). The resulting perception is that X512 is the cool developer working on new features, and whoever decides to do the cleanup appears to be breaking things (as you complained earlier).
So that’s why no one has proposed X512 for commit access yet. Note that other people regularly get commit access (I think the most r cent one was madmax, and before that Kyle Ambroff-Kao). Their patches were not as large, but were better in following the coding guidelines. We value the quality of changes over the quantity.
It is understandable that the work on a new architecture port requires a lot of experimentation and it is not possible to do it cleanly in the first try. You have to try things, make mistakes and go back. And it’s not always obvious how to get that ready for code review. I’m sure that now with the first set of patches merged, we have a better base to work on and if X512 continues work from there, we can consider granting them commxt access soon when we feel that the conditions are met.
I currently see no benefits in commit access or Gerrit privileges. It just increase probability someone hold a grudge against me. More privileges cause more troubles.
Some patches are based on Mini OS code with different code style (CamelCase everywhere, no underscores, same indent level for opening and closing elements, operators go to the line end, not beginning as in Haiku, “*” come to the name, not type). I personally prefer that style and I use it in my projects. Mostly the same style is also used in Oberon projects.
It may be confusing am I writing code for my personal projects or for Haiku code.
It may be easier for me to write working code first and then adapt code style.
It’s never easy to pick someone else’s style. I had some trouble with it when I started contributing to Haiku as well. Now I’m accustomed to the Haiku style and I started using it at work as well to keep things easier for myself. But not everyone can do that.
Thatws one of the reasons we have two GSoC students working on haiku-format so we can have a more automated way to handle this. I think it will reduce problems at least on this aspect
Regarding coding style, at work I’m the author of my employers coding style documents and I’m the chief architect, and I’ve never rejected a patch from collegues or juniors for not adhering to the style spec. I’ll occassionally remind them about it, they can clearly see a difference between their class style and 1000 other classes with the recommended style, but at the end of the day, I always accept the patch even though it doesn’t adhere to the style. Resources are better spent on the next commercial thing rather than a new investment in time to refactor style.
With open source, where free developer time is limited, I would prefer to accept working code by a senior engineerer regardless of style, and then let the juniors volunteer to modify the style. As Adrien has pointed out in an earlier comment, a GSOC student is working on a styling tool, so style related issues should be resolved in time automatically.
