Regarding patch acceptance policies

Off-Topic
#45

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.

10 Likes
#46

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.

1 Like
#47

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.

#48

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.

1 Like
#49

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.

#50

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.

34 Likes
#51

Problem ticket is closed. I consider that case is closed and resume contributing RISC-V related code to Gerrit.

25 Likes
#52

Lets bring back the discussion to the wonderful world on running Haiku on RISC-V :slight_smile:

14 Likes
#53

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? :smiley:

3 Likes
#54
#55

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.

9 Likes
#56

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.

6 Likes
#57

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.

13 Likes
#58

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

8 Likes
#59

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.

Just a pragmatic personal opinion.

7 Likes
#60

If there are problems within the community, it must be allowed to be discussed. Some developers have tried their best to sweep this discussion under the rug by locking the thread created for it and directing us to use alternative, non visible channels. It’s censorship and will not solve the problem.

Discussing the behavior of an individual is not a personal attack.

#61

I am happy to “censor” things here if it’s needed. This forum is hosted by the Haiku project and we decide what the appropriate behavior is here. If youare not happy about that, please find some other place or host your own forum so you can use your freedom of speech there.

In particular when a thread gets dozens of messages from people who have no clue about the technical issue being discussed (again, this was a discussion about wether a specific bootloader type should be used in haiku sources or not), I see no point in keeping it open. It was not interesting from the technical point of view, and it was alsonot interesting from the governance point of view because there was no constructive discussion on that side either. The discussion was better this time on that area from waddlesplash doing his best to explain how he does things, and there were other developers explaining that they disagree with it. That part is constructive. But random community members demanding that a developer is banned in public? That’s not constructive at all and only serves to stir up the controversy and prevent cool and calm discussions. So, please stop.

If you have problems with specific people, you can contact them privately instead of stirring hate and asking the mob to lynch them here. If private discussions don’t go anywhere, you can use the forum features to signal inappropriate posts to the moderators, or contact them privately as explained in our “policies” page.

There is no point

25 Likes
#62

Would you accept patches without documentation with just “fix riscv” as commit message?

1 Like
#63

We davon germany: “Der Ton macht die Musik” (The sound makes the music), in other words, it depends on how you criticize something. the post contained personal, aggressive comments.

I could understand this step. the forum operator is responsible for its content and has the duty to intervene when things go too far.

5 Likes
#64

If you would like to have a hand in developing Haiku, please step up and start submitting patches. The process is pretty clear.

Community feedback on features and design decisions is helpful (and needed!). See Sending data to 3rd party (regarding Gerrit #1875) for a good example of this.

Community feedback to developers (working for free) telling them how to develop (while you are not helping develop) is not as useful nor wanted.

I personally value X512’s feedback on the way things are.
I don’t value external perspectives as much.