[haiku-development] Re: Banning Barrett

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 17 Mar 2019 21:58:45 +0100

Le 17 mars 2019 13:00:53 GMT+01:00, Dario Casalinuovo <b.vitruvio@xxxxxxxxx> a 
écrit :

Hi,

On Sun, Mar 17, 2019 at 9:08 AM Adrien Destugues <pulkomandy@xxxxxxxxx>
wrote:

Le 16 mars 2019 15:59:21 GMT+01:00, Dario Casalinuovo <
b.vitruvio@xxxxxxxxx> a écrit :
Hi,

On Sat, Mar 16, 2019 at 8:47 AM Humdinger
<dmarc-noreply@xxxxxxxxxxxxx>
wrote:

So, Barrett, after years of people criticising your lack of

communication when it comes to your contributions,


So, as said I don't think I did all that different than what for
example
Axel did with launch daemon,
and the codec kit isn't all that revolutionary after all compared to
it.
The difference here is that he
discussed about that at begeistert and that there was the
possibility
of
having personal branches.
This is another problem, this is a problem of management on admin
side.

There never were personal branches on Haiku servers since we switched
to
git. People usually just use github for that.


This is another thing that I don't like about how discussions goes. I'm
of
course referring to tracking external branches. There's no point in
putting
the stuff on my own github if in the end commits doesn't get in
haiku-commits.

You can manually ping the mailing lists when you have something to review, or 
indeed kindly ask the admins to setup the notification. You are right that this 
process is not perfect because it requires manual intervention from the admins.

I could also argue against private branches, once again a thing that people use 
to state their ownership of some feature or part of the code. We have seen this 
sometimes succeed (Jessicah's work on uefi) and sometimes fail (aldeck's 
Tracker refactor).

I still believe collective work through Gerrit would be more efficient, but I 
admit it is a personal preference, and you know that I pushed a lot (started 
right after the alpha 3 release) to get such a tool deployed. With some 
dedication and patience I'm sure you can get the admins to deploy a better 
system for private branches. And please don't tell me you have no time to waste 
with that. Your time is as precious as everyone else's here.



* Finally, in another situation sometimes someone come from nothing
and
begin speaking about stuff that didn't even have reviewed correctly,
I'm
not going to accept lessons from someone who didn't respect or
consider
my
ideas in the first place. There's also an example of that in this
topic.

As I already mentionned, systematic code review is a great tool for
that.
It is an opportunity for you to document your changes.


Here I refer mostly to some people like honorable members of the Inc.
that
comes years after to criticize me that I'm not fixing memory bugs. 

Please no personal attacks, even if hiding the names...
You may have noticed that I was the first on the forums to tell waddlesplash 
that this was not appropriate. I did so in a polite way and did not need to 
call him a "who's this child". He puts me as responsible for not fixing bugs in 
WebKit as well, and I keep telling him that I'm happy to get help. And 
accepting his criticism because he is also right: I did not fix these bugs, and 
the fact that anyone else could fix them doesn't change that.

At
that
point I had +2,5 votes for my work to continue, I needed just another
bit
to get the majority and the subsequent "go ahead". Now, I will not
accept
his critiques about my development, I don't know if he voted -1 or just
abstained, it's just that this person lost any consideration from me.

Can we all agree that no vote was held and there was premature action from one 
of the admins? Can we set this aside and discuss the core of the issue? I agree 
it is not nice for you that this happened but I can't apologize on behalf of 
Kallisti5 for it. And yes, we definitely need tosit down and write down the 
rules for voting. It is not the first time this is brought up, including by 
myself.


Code reviews are another different question, it's science after all and
if
someone make a good point I may consider it. It's just that if I were
in
that person I'd have the decency of keeping my mouth closed instead of
showing my lack of understanding of the situation.

You are being aggressive again. I tried to explain you that people asking 
stupid questions is precisely the point of code reviews. If you don't want to 
take the effort to go through this and educating people (who are, again, not 
questionning your choices, but merely trying to understand them), then you 
can't work in a team at least with me.

You want to design a new media kit on your side without the input from other 
devs. You can probably pull it off, you spent a lot of time studying the 
existing code and have a clear picture of where you want it to go. But I think 
this way of working is unfit to working in a team like Haiku, where we try to 
play in a more collective way.

Those peoples are
just
politicians keeping a seat, and those people are very dangerous for the
project IMHO. I will never return again on that.

No conspiracy theories please.
There is no "keeping a seat" here. Do you perceive that being anadministrator 
(both sysadmin and paperwork kind) is not a position of power, but of 
execution? It does, however, give people some responsibilities, and by removing 
your commit access and banning you from the irc, yes, I think Kallisti5 has 
abused the powers delegated to him. But I also understand that our rules are 
not written, and I will assume no bad intention on his side. This means once 
the issue has been clarified with him, I can trust him that it won't happen 
again? Do you, or will you stay with the assumption that he is trying to harm 
the project or one of the contributors (you) to protect some personal interests?



I can take the example of the metadata handling in Media Kit. Several
developers have suggested the use of BMessage for that, for
consistency
with other parts of the API (it would be one less class to worry
about for
the people using the API).


So, here I tried in many ways and in many times that it's just a
coincidence that BMetaData uses BMessage internally. It's not even
assured
it will continue to work this way, because, when it comes to handling
media_headers I'm a bit worried of the relatively expensive (linear)
operations done internally. This class is really special, and is
conceived
to solve a lot of problems around and have various operations which
can't
be implemented into BMessage. Like joins and selective matching. I'm
not
going to extend more because at this point I'm going to keep my design
private to avoid others use my ideas.


I think you did not want to admit this point of view.


So, I had a talk with Axel about that, it all started because you and
waddlesplash told me he just resigned from the discussion. I think, we
got
to a point where we both agree it's a question of taste. We both agreed
we
didn't have enough arguments each other to convince enough. I think he
told
me that in the end he trust my judgment enough to be OK with that.
Also, we
got to the point that the class could be easily removed from the tree,
but
if someone did that someday he should have strong reasons as well to do
that.



In general, what I take is that you want to make things better, but
by
doing so, you are ready to lose the consistency, which I, personally,
value
a lot and am ready to compromise other things for.


If you only seen my complete design I think you'd change idea and
understand why it's really a bad idea to implement my stuff subclassing
BMessage. Because that's what we are talking about in the end,
subclassing
vs wrapping BMessage.

The problem here is that I blame you for not sharing this design in the first 
place, keeping it in your head and wanting to keep all control on it. The fact 
that now you do not want people to "steal your ideas" reinforces my conviction. 
You don't see how collective discussion could lead to better design. Maybe you 
want the credit for it personally, I don't know. 



I think this is one of the keys to the Haiku spirit. It does not make
your
changes wrong, but I see them somewhat not fitting with Haiku as a
whole.

These things we can discuss at length, if we manage to both keep calm
and
not lose our nerves. But it takes code review and presence on the
mailing
list.


I have a fear that a pattern I already seen multiple times makes me to
quit
the project. I see a pattern from waddlesplash often and you can see an
example of it in this mailing list:

* I say something, commit something, comment on something and he just
goes
on me with a -1
* Then someone like you or Axel comes, and he either change idea or at
least gets more reasonable.

A typical example of discussion and review. I often ask people in code reviews 
why they do things this or that way. They explain it to me and I improve my 
understanding of the code. That's it. It is not an attack or putting your 
skills in question, it is just a way to learn something about the code.


A little variant of this pattern is "Be did always everything right".

This one exists only in your mind. Of course they didn't and we have 20 years 
more of experience dealing with their mess. Yet, we are trying to get Haiku R1 
out, and for that we decided to live with the limitations of their design. And 
we try to stay focused on that goal, no matter if it isn't perfect.


Now suppose that happened with a -2 on by BMetaData stuff, I'd not have
done the 70 commits that comes after that because I'd have probably get
unmotivated. I have just a few mins per days to dedicate to hobby
programming, if I see those patterns happens often it's normal I'm
scared
of gerrit.

It is part of the process. You have to find the motivation to convince people 
your changes are going the right direction.


I see also a bad pattern from you, I just join in IRC to discuss wheter
read only volumes should be ordered or not. I don't think I criticized
anyone, if any I've been criticized a-gratis from you and waddlesplash
just
for questioning something. If you want to collaborate with me, you
should
know that I converted myself to a "nullius in verba" style of thought.

As I already mentionned, at this point I am not able to discuss things with you 
and I lose mynerves very easily. People who know me can tell you how patient 
and cold blooded I usually am, but you managed to reach my limits. So I get 
emotional and irrational, and this happens very rarely for me so I don't have 
much self control on it. Sorry about that. There is unfortunately not much I 
can do, and this is why I should probably ignore you on IRC, unless we can 
discuss this and reach to something that solves it for me.

I
question basically everything, but with the purpose of bringing new
ideas
and different ways of thinking. In the end I always trust the most
expert
person in the field.


Even with the development plan you outlined, it still seems you would
prefer to work in "code drop" style: submit us a complete
implementation,
docs, etc, of your own design.


It was up to you to take the implementation. Since I felt that a
disagreement on something like BMetaData which to some extent is
relatively
irrelevant to the codec kit (but not to the media2! it's very important
there) could have mined the plans at a whole, for the reasons stated
above,
I think seeing the whole implementation would have clarified a lot of
things which are just too difficult to see if not in whole.


I believe the way things are done in Haiku deserves more concertation
and
discussions. Yes, that means we are much slower, but this is how we
can
keep running the project without any leader. The choice of giving
even
opportunities to everyone to raise their voices has a cost and I'm
willing
to pay it because I think it pays in the long term.


This is fine. But at some point you either trust the judgment of the
person
willing to work on it, or it's just going to be a pain in the ass.
I've been criticized to do long discussions about details, I think it's
actually other people that points always to details instead of the
whole
image.



As you see, my arguments are not so much on the technical side here,
I
just think your way of working does not match with how I see Haiku
and how
I think it should run. I don't think it is something that can be
fixed.
There will always be frictions resulting in wear on either side.


There are always frictions. But voting on everything isn't always going
to
work.

It's not about voting, it's about explaining and discussing the choices so that 
people understand the compromises. If you manage to have people remember "we 
can't use BMessage because we need unions and intersections for filtering the 
appropriate codec for the file", we can all stand back behind it. Otherwise all 
we can say is “Barrett says it's better and we don't really understand why". 
You do not earn my trust the latter way, even if eventually the code works 
perfectly.




The question is, since Adrien seems to like a lot gerrit and code
reviews,
why don't him use gerrit for that? And why he doesn't push to
actually
have
webkit commits routed to haiku-commits for proper review? I'm pretty
sure
it'd be an excessively annoying thing for him as it's already a
difficult
area to develop without people questioning.

"when in rome, do as the romans do".
I work on WebKit, I use the rules of the WebKit project. I asked them
if
they were interested in upstreaming our port, and they said not until
we
give up on WebKitLegacy. It looks like one of our GSoC applicants is
finally taking care of this, so we may start to upstream code again.
And it
will of course go through WebKit's review process, and any dev who
contributed to WebKit can tell you how much more annoying than ours
it is.


But they are paid quite a lot to do that...

And I should also mention that most (I dare not say all, because you
will
find some direct commits now and then) changes I make to Haiku go
through
Gerrit, and that I push other people to use it more as well. Some of
them
think it should not be mandatory, but I'll keep encouraging them to
use it
more (and try to not be to annoying in doing that).


As said I'm scared of the pattern where the random waddlesplash is
going to
-2 my patch and drain my motivation for weeks. I'm not sure the project
is
ready for that. But as said, you and your friends (not me since I've
been
illegally removed) you can vote and you can do whatever you want. I'm
not
even sure at this point I'm discussing about cooperating with you or
just
the relics of that before I disappear.

It's not a matter of friendship. I work here with people I know a little and 
other I never met in real life. They know very few things about me and 
likewise, I don't know much about them. There are people from who I learnt a 
lot, others I see growing and acquiring new skills over the years, but it is 
quite a professional relationship. 

Also, seriously, do you take a -2 that badly? It is part of the review process, 
it is not a personal attack. It happens all the time. When I put something 
through review, I want people to find problems with it. This means they care 
about my code, take the time to read and try to understand it. If it gets 
merged without comments, I'm worried that they trust me too much and did not 
put to the code the attention it deserves.





So, we are all good at predicating things that we don't follow in
the
first
place. Adrien is good without reviews, we don't have any idea of
what
he is
doing, and he rarely explains us what are his plans. Now, again,
this
is
not a critic to him, but do you see the parallel?

I'm not doing much. 99% of my work on webkit is merging upstream
changes
and making sure the code still builds. And it does not take an expert
eye
to see that the result is an extremely unstable browser that's
unpleasant
to use.


I'd have been very happy to see those go in my email by default.

Just star the repo on github?
I can understand not every Haiku contributor wants to have this in their 
mailbox.





Suppose that if I'm forced to go through gerrit, also Adrien should
be
too,
what happens? Let's see if there is justice and equity in this
community.

I'm fine with mandatory Gerrit for every change.


I'm -1 for the reasons stated before. I don't fear you or Axel because
I
think in the end the discussion is going to be meaningful, but I fear
other
people cold-judgment without even reviewing my work correctly. 

Using proper code review tools help. People who don't read the code usually 
don't lurk there. It allows to keep discussions in context and more focused.

I'm really
slow to make an opinion on changes, that's a precaution I take each
time to
do not try to mine others motivation.

You are still perceiving code reviews as an attack, as if you need to protect 
your code from something. I don't know what I can do about that. Please do ask 
stupid questions and give your initial feeling on code too when reviewing it. 
Sometimes after reading it 3-5 times it becomes more clear, but then maybe the 
code can be reworked to make things more obvious?



Nonetheless I have to say that someone finally acknowledged that
it's
really painful to use the gerrit review for the kind of work I'm
doing.

I will mention again that it is a way to have other people read and
understand your work. If you do not go through this, how are we going
to
understand your code?


It's not always possible to make a net judgment on early patches, it is
a
danger that can make more developers to quit rather than helping the
project.

I don't think so. And if patches are not suitable, start with triting 
specifications, a thing that can also be done collectively, and this time the 
mailing lists indeed are the appropriate tool. As long as we can ceep a 
civilized tone, of course.



I'm pretty sure that, for example Vidrep, which follow my work with
a
lot
of interest already knew what were my plans. I had long discussions
with
him about my plans that were in the public channel.

Also, people please stop saying that I bypass reviews, until a year
ago
or
so, reviews where done only in the mailing list, and that's where
those
are
supposed to happen.

Post commit reviews result in more frictions, because it is annoying
to go
back to already commited code. Gerrit encourages me to push work in
progress changes for early review, and more efficiently collaborate
on
things. I see it as a way to use other people brains to improve the
design
and clarity of the code. I can see that not everyone agrees with
this, but
I don't see how you can complain that people don't understand what
you do
if you are not willing to get through this.


Not sure, it worked OK for quite a lot of years. Suppose the package
kit
was implemented this way, I clearly remember some people being against
it
initially, then gradually changing idea and some in the end became
lovers
of it's design. Now, Ingo was somewhat right from the begin, the clear
image of what he did could be seen only years after it's work.

I remember this completely differently. The work on package management was 
first a large discussion involving contributors and the community, to gather 
all the needs (installing/updating/dependencies/...) and all the technical 
possibilities.

I specifically remember suggesting that we have a look at RiscOS applications 
(which are a directory with a special name, allowing self contained usage and 
easy distribution without filesystem tricks), as well as the way Amiga manages 
the path, include path, etc by using "assigns" (allowing to merge multiple 
directories as a single volume). You can easily see how these have some 
similarities with the final design. There was of course lots of other valuable 
input from others.

This collective brainstorming session led to an "ideal" design, our dream 
package manager with all the features we needed, and a good idea of how we 
could implement it (the packagefs). We were, however, not sure if it would work 
and be fast enough. Also Ingo was not alone working on this, olta was also 
involved in implementing it (this information was available on the old Haiku 
inc website, but is now gone...). It is correct that Ingo's contract lasted a 
few month more than Oliver's one.

Eventually there were a few compromises (non-packaged directories and the 
deprecation of B_COMMON directory constants are the most visible), but the code 
conforms to the initial spec. I find it interesting that you retained a 
perception of the "lone genius" pattern, where I see a good example of how we 
can pull off great collective work.

I do have some complaints about the code developped as part of this. You can 
see in it that people writing it had been doing Java a lot, and you find some 
patterns not common elsewhere in Haiku because of that. However I was also 
briefly involved, with changes in the pathfinder APIs to better support the 
needs of the locale kit, and later on when I reused the zlib support classes to 
include them in the http library (I had missed something very important in why 
the zlib classes are not built around BDataIO, and I pushed my code directly, 
and Ingo had to revert and fix it. This would not have happened with a proper 
code review tool in place).

I don't
know
if I explain myself, but I hope people see how not all development
styles
are going to be correct. There's another face of the medal, no one is
basically expert enough on the package kit now, and this probably
should
have been worked better. I'm not saying your point isn't reasonable,
but
there are different colours to take into account before saying that
it's
the only correct way to develop things. As said, I think personal
branches
are better for mass refactors.

I did not say it is better. I think it is the currently preferred way in Haiku, 
or at least it is mine.
But the main problem is not there. If you want to work in private branches, 
that's fine, but then it is expected that people don't understand your code. 
You can argue that you work faster/better/more efficiently, but I think the 
longterm result is harmful to a project like Haiku, where I value the 
collective undersanding of the whole codebase over the functionalities. I think 
this is the only way we could keep a project like this running for 10 years 
(since I'm around - don't know how it was before) without any large rewrite or 
refactoring of a component. I find it awesome that our codebase is clean enough 
to allow that.






You want to keep being a member of the project and fight for it;
putting us and foremost yourself through this ordeal.


Let's put it this way: I've been illegally removed from virtually
any
thing
in the project, I'm no more part of the Haiku organization anymore,
I
have
been banned from #haiku-dev, my keys have been revoked, and that
happened
in just 33 hours. From the (private) comments I received, people
indeed
recognized it as an injustice and a partial decision.

Not only private. I have stated multiple times in public channels
that
this way of handling things is completely unappropriate.


Believe me or not, I'm going to say this now and retract at the same
moment, there's a silent majority too.

It would be great if it was less silent. People, I hope you have contacted 
Kallisti5 to (politely, of course) tell him you think his behaviorwas not 
appropriate. Just like in code review, I appreciate when people warn me when I 
do or say things that I shouldn't.





Before think about removing this illegal situation and restore
everything
how it should be.

I agree, however your mass revert on Gerrit does not help your case.
Can
we now trust you to not do ill-intended changes to the git
repository?


You removed all my credentials in a matter of few hours, and as said I
think that if those things about me are true, you should work your own
way
through the issues. 

Have I not been clear enough that I don't condone the premature removal? Who 
are you including in this "You"?

Also, be clear to the readers, that I didn't revert
all
my git history, but just the codec_kit changes which are disputed here.


Indeed, sorry for the misunderstanding.


On my side, I started this topic because at this point I have
concluded
that collaboration with you in Haiku is physically affecting me.
That's
unfortunate, I think it is nothing personal and maybe we could try to
collaborate in different settings.

I am annoyed (and it's not the first time) by Kallisti5's "move fast
and
break things" approach to this. It's abuse of sysadmin powers and
that's
not acceptable. I hereby consider him warned about this and hope it
won't
happen again. It does not help that we never wrote down the rules for
this
in an easily reachable place.

It isn't even clear for everyone what a "ban" is. Does it include
removing
one from the whole community? Removal of commit access? On voting
right for
project decisions? I don't know, I think indeed a complete ban is an
extreme mesure so we have to strongly agree it is the right thing to
do,
but on the other hand, at this point, would a compromise solution
work? Can
there be trust?


I'm still today banned from #haiku-dev (which I think is really the
worst
thing of all).


I agree with Humdinger. Independant of our issues on working
together, I'd
say we all want Haiku (or let's say, some BeOS inspired project,
whatever
it is) to succeed? So, why threaten for more roadblocks on the way to
that?
By doing that you are trying to harm Haiku in every way you can. The
fact
that you are even considering such things is worrying for any future
collaboration.


I expressed multiple times that I want the situation to change
promptly, I
can't say more than that.


Can we safely keep using any of your code now, or willeit lead us
into
more trouble?


Probably not, who know.



It would be great if you could show more trust into the project,
despite
innapropriate actions from some members (we all make mistakes). But
you are
reacting with attacks, and this does not help me being reinsured thut
collaboration is somehow possible.


You should have thought about that before attacking me (I mean the
ban).
You can't question me for defending myself and actually requesting that
the
disputed changes are reverted. And as said, believe me or not, I care
much
more about seeing that code lying there for years than for the commit
access itself. I think with me the project will lose a lot, and in some
way
this will begin a "third republic" in the project history just like it
was
after koki's ban.

If we can finally get our management rules written down, that would be a good 
thing, I think.

I have explained already how I ended up going to such an extreme solution. I 
know it is not an easy thing for anyone. I hope you understand that I am 
annoyed by Kallisti5 prematur.action as it is in direct consequence of this 
mail, so it makes me partially responsible for an unacceptable abuse of 
authority. I want this to be clear.

It also makes it even more difficult to discuss things in good conditions. I 
really want this to be a fair decision. If other people decide that you'd 
better stay in the project, I will conclude that things indeed did improve on 
your side and that I must work on myself to not over react. Itrust their 
collective judgement better than my own. I still think we could get through 
this with a positive outcome for both of us. I hope you understand how going 
through this was required for me, I need the definitive vote from the team to 
know where to stand with this. I will accept the result, whatever it is, but I 
think we had to go through this discussion to clarify various things. Thanks 
for taking the time discussing all this and staying mostly constructive (again, 
no one is perfect and some wounds are not easily healed, especially with that 
happened here...)


But, with your reaction of mass reverting everything on Gerrit, I must
admit that it was not completely wrong either? What would you have
done if
your commit access still worked when you found out about this? Would
you
have reverted all your work directly?


Yeah, drop a nuclear bomb on a state and then say that it was just to
prevent more damages. Sorry I don't think I'd have done that if I
didn't
have a gun pointed on my head.

Both the nuclear bomb and the gun are I think exagerated (but Axel also already 
used the railgun analogy, so there is probably some truth to it). So again to 
make this clear: I want this to be handled cleanly and by the rules. There is 
more value in the discussion than the eventual outcome. I'm sorry for going to 
such extremes, and even more sorry for the premature action that happened 
because of this and clearly did more harm for no valid reason. This is not nice 
to you, and it is not how things should be run. I also want to say that 
whatever the outcome of this is, I hope you can find a way to keep the BeOS 
spirit alive in your own way, be it in Haiku,  in V\OS, or whatever you decide 
to continue with. It's just that I did my best to collaborate with you, and I 
think our way of working are incompatible and this would be quite hard to fix. 
I will not assume that the whole team agrees with me, I hope to read about 
their views on it. Maybe that can help me adjust my point of view.

-- 
Adrien.


Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2019