Code review, technical decision-making, and intent

I’ve read the discussion, and even though I do not have the technical competence to fully understand the technical part, I fully agree with you. Your argument is basically that you believe that it is the best way to go and that it will avoid using third party code that we do not control and that leads to bloat.

Jessica’s argument is that it is not the way it is supposed to be done and that other OSs (FreeBSD and Linux) do it her recommended way. To me they are not valid arguments. If there are better ways to do it, then what you are supposed to do or what others do are irrelevant.

Do it your way. If others want to do it in any other way, then let them.

7 Likes

I am not a RISC-V expert, but I certainly can understand and follow the arguments, and I am largely in disagreement with X512 here. (It is worth noting that this is entirely a technical discussion, and so if you do not understand the precise details of what is being discussed, it is pretty easy to choose sides for errant reasons.)

I think you are inadvertently committing a fallacy here. She is saying that it is not good to do it the way X512 has done it for (list of somewhat complex technical reasons). Someone who does not understand those reasons may think that she is thus arguing on the basis of some kind of authority, which is not at all what is going on here.

That is not really a great way to build community projects. Consensus is required to build things in community; if that happens naturally and without concerted effort, then that’s great! If it happens by deliberation and everyone still comes to an agreement, that’s good too. But ultimately, if it happens neither organically nor by debate, at the end of the day, it has to somehow be reached, and sometimes that just happens by majority consensus and whoever is left over will have to accept some kind of compromise.

Haiku has proceeded slowly and meticulously because we care about details, quality, and doing the right thing; not the quick thing or the easy thing. We have not hesitated in the past to go against the grain of what other OSes do if we think something else is better. This case is no different: that is, we are not going to just decide to do something simply because other OSes did it some way; but we are going to study why they did it, and if we agree with their reasoning, we will probably do the same, rather than doing something different for lesser reasons.

I will attempt to give, in my next post, a “layman’s explanation” of the argument in question.

2 Likes

List the reasons. I have not seen any technical reasons, only how they want it to be done or how others have done it.

Says the one developer that has no problems running over the will of other developers and committing directly without review.

I never argued against majority consensus. I argued for @X512 to do it the way he feel like doing it. If others (ie your “majority consensus”) wants to change it, then let them.

And how come Jessica can vote on Gerrit? To my knowledge she has not committed a single bit to Haiku. She could be a trojan horse for all we know.

Patches are welcomed. They won’t come from @X512, as he clearly stated.

The technical reasons are listed out right in the comments on Gerrit. You specifically noted that you do not have the technical competence to understand them; that’s fine, but that also means that you are missing a large chunk of the argument. See my post just above attempting to summarize.

Do you really need such an aggressive tone here? (Is there something you have against me that I’m unaware of?)

Gerrit was instituted as a convenient way to review patches instead of linking people to feature branches or uploading patch files to Trac. It is not now and has never been mandatory (though indeed some developers choose to upload all of their patches to it without exception.) I personally upload patches that I think or know will need review from others, and continue to commit directly things that are probably uncontroversial.

But I certainly don’t intentionally “run over the will of other developers,” and I’m not sure where you are getting that idea from at all. If it turns out that something I committed directly is in fact controversial, I’ll rapidly amend or revert it.

So, I do not think your overly aggressive accusation here even has merit.

6 Likes

Anyone is permitted to give -1/+1 votes on Gerrit; you can do it too! (Only developers can give -2/+2.)

Do you have any grounds whatsoever for this accusation? Because I don’t see any.

On Haiku, we try to evaluate people based on their technical abilities and contributions before other concerns; a (quasi-)“meritocratic” environment. There are, or at least used to be, some contributors that were so anonymous I knew basically nothing about them besides their handle and maybe an email address identical to their handle, and nothing more. So, I would hope that if anyone was a “trojan horse,” we would find out about it based on what they said and did, and not by going on some kind of witch hunt about it.

Anyway, Jessica Clarke noted on another Gerrit change that she started looking at the changes on Gerrit after a conversation with @kallisti5 on some IRC channel about how paging works on RISC-V while he was working on the EFI bootloader for it. So, she didn’t just appear totally out of nowhere, though if she had, it would certainly have been far from the first time a contributor has done so.

4 Likes

And I don’t see any accusations, only a question.

Intent is important to me. I see that @X512 has a good intent.

The open source world is full of trojan horses. Stallman and Torvalds being the two most important. Their intent is bad. I won’t go in to details. Do your own research. Wikipedia is all you need.

Well, I would not bring conspiracy here. It is just her opinion. She give some helpful opinions and clarifications, pointed some problems like race conditions. A appreciate for her technical comments.

I think that technical and ideological discussions should be separated.

11 Likes

That’s how a trojan horse works. Build trust so you can sneak in your agenda unoticed.

And I didn’t accuse her of being a trojan horse, I only stated that we do not know her intent by using the frasing “She could be a trojan horse for all we know.”.

Her loyalty is probably with RISC-V, not Haiku.

In case you haven’t noticed, we’re not the biggest fans of either one of them around here, and we certainly don’t model ourselves after them or their projects as a rule, so I don’t know why you are bringing them up.

I don’t see a question mark (referring here to your accusation against me.) But your question about a “trojan horse” is an accusation, as well.

If you don’t intend to stick to polite conversations, and just throw out unsubstantiated accusations, and then ignore attempted rebuttals, you can expect to wear out your warm welcome very quickly. Tread carefully.

3 Likes

Excellent! That means that we will test our mettle directly against someone who has no particular reason to support Haiku, and see if our arguments still hold water! And if they do, then we will go on our merry way all the more sure in the decisions we have made. And if they don’t, then we will have learned something and improved Haiku and ourselves for it. So it’s a win either way!

I couldn’t care less. I do not self censor because somebody might get butt hurt. I hope everybody do the same, because the world would be a much better place if we stick to the truth. If you don’t like what I have to say, just ignore me.

She never swear for loyalty for Haiku as I remember (me too, I free to do I want). It seems she works with FreeBSD.

2 Likes

My point being she is used to doing things her way. She might not know what is best for Haiku. FreeBSD and Linux is made up of several independent parts. That is what is wrong with them. To many chefs. Haiku’s strength is that it is homogenous.

And I don’t say that your way is the correct way (because as I have stated I don’t have the technical knowledge). I stated that I think that each developer should do things his or her way. It is then up to the community to decide to accept it or not.

As I explained in my prior post, that may actually be even better! She will have no reason to hold back or “self censor”, as you put it. So I still do not know what the issue you are seeing here is.

I replied on Gerrit attempting to give a basic defense (and here, though in somewhat different terms) as to why this is not a sustainable attitude to run a software project around. We cannot just have organic consensus, that is a recipe for projects rapidly falling apart at the slightest of disagreements.

You keep on interpreting what I write totally wrong. You are to intelligent to do that over and over. To me it feels like you are trying to manipulate what I write to suit your agenda.

I have only stated that the rules the developers have should be followed. That usually includes discussions and votes if necessary. I have not argued for “organic consensus” (whatever that means).

I am not sure how to reassure you that I am most certainly not trying to do that, so it seems somewhere we are just not understanding each other here.

Perhaps we should communicate by another medium (IRC?)

Even more, he deletes +2 reviews of other persons. Why this is even possible?

waddlesplash
Removed Code-Review+2 by Alex von Gluck IV <kallisti5@unixzen.com>

I think that it is bad practice, all changes should go through review.

1 Like

Gerrit automatically deletes +2 reviews when uploading new patchsets. Jessica’s comments on that change indicated what appeared to be some critical fixes. I didn’t have any particular objections besides those (as I didn’t review the patch in great detail), so, removing the +2 in that case seemed like the right thing to do. (Would you have preferred I simply add a -2, which would not be automatically removed on next push, instead of removing the prior +2?)

Well, at least at present, we do not have such a policy, and there are still a number of changes that are pushed directly and reviewed after the fact besides a number of my own.