Attention is currently required from: Arthur Heymans, Jonathan Zhang, Johnny Lin, David Hendricks, Stefan Reinauer, Christian Walter, Deomid "rojer" Ryabkov, Tim Chu.
1 comment:
Patchset:
Hey Stefan, I thought it's time to open a new thread for this. There's
just so much to write it seems.
From an outside perspective without having skin in the game of this specific issue: Forking is not always bad. If there are two opposing trains of thought that can not be unified properly, or if there is a lack in will to make that happen, allowing everybody to move on and make their own version better for themselves and their customer base can even help to overcome differences in the long run (see egcs vs gcc a long time ago).
I agree and this is why I bring it up from time to time without meaning
it as a threat.
At some point it is better to try this out and see if it is what you think it is.
For your own peace and that of everybody else. I for one would be excited to see different directions take place at the same time. That's much more energizing than yet another community where people don't get along.
Now I'm completely confused. In this project, flashrom, I'm not aware
of any doubt about my involvement until we started to try to bring a
fork back into the fold. That this effort was started shows to me that
people were not very excited to see different directions. So, the exact
opposite of what you just wrote. Can you elaborate on that thought? Do
you think it's a bad idea to merge the chromium fork?
Nico, you are unhappy with about everybody trying to work with you here,
"everybody": About 1 out of 10 people and only 1 in total long-term.
Admittedly I am bad at keeping lists. It seemed to have been everybody that I have worked with, at some point, but that may very well only be a small portion of the flashrom contributors. I apologize if I managed to become your long-term foe.
No-no-no, not my foe at all! :) This wasn't about you and I don't see
anybody as mine generally. And I hope of course that I'm nobodies foe,
but I don't know that.
My only long-term unhappiness is about trust issues I have with Edward's
work. Lost trust takes time to build again, I wouldn't be surprised if
it takes a decade in this case.
About the "list". Are you sure you mean it as stated "Nico, you are
unhappy..."? Or do you mean that everybody is unhappy with me? Because
I could only name three to four people in the whole coreboot community
that I've really been unhappy about. And if everybody that you have
worked with was unhappy with me, that might be good to know for me.
and you are offering to fork the project fairly frequently.
About once per year since Google tried to converge their fork with brute force.
Look, "Google" is not trying to do anything with brute force here. David, for one (who has not been at Google for many years), never really bothered if upstream would like the code contributions that he managed to integrate from the Chrome OS team. He was criticized for letting things diverge, and so another person came along, and another, and none of them were seemingly able to make much progress here, even decade long contributors to coreboot were in this list. That is not a sign of agressive convergence or brute force.
Argh, sorry for putting it like this without explanation. Stefan, I
honestly appreciate that you keep talking to me even when I badmouth
things. It was meant roughly about the last 2.5 years. Back when
things diverged, I wasn't even involved with flashrom. I guess I
just started to work on coreboot at that time.
It was during these last 2.5 years, that upstream flashrom was con-
fronted with commits that were a mere diff of a part of the master
branches of upstream and chromium, with made up commit messages.
This is what I call brute force. Once such a commit is merged, it
deceives anybody who wants to look up the reasons for the current
code state. And this stays in the Git history. If the committers
did this on there own or if they were tasked by Google with upstrea-
ming, I don't know, I admit it. But at that time I assumed the latter.
Please Stefan, imagine for a moment a commit that is actually a revert
of a fix but the commit message says it makes things better. I remember
one of such commits that made it in and one that didn't. But not knowing
how many made it in is a huge issue.
Ah, one more thing that I consider brute force; this was not Google's
doing, though: Edward got submit rights to the repository without any
prior involvement with the upstream project. Without saying hello even.
Now, Edward came along, and Edward is an assertive guy that follows up and follows through, and that can be both a blessing and a curse. I myself have been a complete jerk to Edward when he tried to merge LLVM support into coreboot at the time many years ago (and I never appropriately apologized), because I felt that he was diverging the direction of the project away from the stable construct that we had at the time to something that is too in love with the tools and programming languages used. I felt at times the same about Rust, go, and Ada. Today I feel that I would have been better off seeing Edward's work as the investment that it was, instead of a destructive intrusion. Luckily by the time Ada came around, I had already learned a lesson there.
It is unhealthy for you and everybody else involved in this project to keep the threat of breakup over everybody's head. I would encourage you to think about whether that is what you want and if so, I will gladly help you with resources (hosting, etc) to get your fork started and off the ground. I will also gladly pay for a domain for you for the first couple of years.
That is a nice offer. But what is holding me back is not the lack of
resources, but the people who ask me to continue and get another
release done eventually.
You can of course do another release also from a new project. Life does not stop at any single moment but the last one. I hope you will be releasing software for decades to come, no matter what the project. My understanding was also that you have officially resigned from the flashrom project a while ago?
Yep, I resigned. I've started to look into it again after a year. Right
now I'm trying to keep it to things that nobody else does. I guess that's
what we all do equally, as the project has no lead.
You said "new project" above. You may not expect this, but if I'd fork
flashrom, I'd do it to continue the project and I'd also ask you for the
domain name oO
We have all started out as friends in this project, and it is good to remember that in the end we share 95% of the same goals, even if we like to fight to the last breath over the remaining 5%. Let's not use those 5% disagreement as a reason to create an environment in which none of us wants to be. It's not worth anybody's life time.
This is one of the misunderstandings in this project. We don't share 95%
of the same goals. And I don't think it's wise to ignore that. On one hand,
there is flashrom, the thing that is packaged in long-term stable OS distri-
butions that is used by humble users and needs to be 100% reliable so they
don't brick their machine (or at least reliable enough so we are not buried
under support requests). On the other hand, there is flashrom, a development
tool. For most developers flashrom is the latter, I think.
Please don't ignore diversity.
As grown-up people we can often hold conflicting goals in mind at the same time. I would still hold up that 95% of our developers are interested in creating a tool that is both capable of stable OS distribution as well as use as a development tool. The degree to which one lets the project encompass both of those goals and juggles the objectives successfully is leadership.
That's why I quit back then. I'd like to think David and I did a good
job at that and that I also did well when David spent less time with
the project. But then what I called brute force happened and it was
impossible to keep the stable goal in sight without having to argue
about it constantly. You were involved too, AFAIR, you showed up on
Gerrit in one of such arguments and I don't think you were juggling
with more than one objective at that time.
I don't think that I ignore diversity, although your line of thought is compelling there and I would like to know more about how you get to that conclusion.
Because you said 5% disagreement. That sounds like something one could
ignore. If one assumes that little disagreement and maybe even communicates
it to their superiors, it's more likely that people are caught by surprise
when things escalate. People won't schedule time to settle disputes for 5%.
You said these 5% should not be used to create a bad environment. But
that doesn't mean we can ignore them. Also what should one leader do if
developers do exactly that, create a bad environment and then the leader
of the neighbour project backs them up doing so? Now that I re-read
your original 5% comment, I think that is exactly what people did when
trying to upstream things from the chromium fork.
I am open to suggestions but this way of treating each other needs to stop.
Ok, then we need to talk about how people are treated. Please, Stefan, advice
us what we can do better.
I think - and this goes for all of us - that we will be better off putting us into the other person's shoes before alleging that they are only out to hurt us,
Hmmm, that's a good idea. I tried, though maybe not with the best strategy.
I asked David how it is possible to move on here without being forced to
work on his patches. But I didn't get an answer. So I assumed it's all
intended. Maybe it wasn't. What would you suggest how I figure it out?
or even worse "the project" in a religious assumption that only one side can determine what is good for "the project".
Well, call me a zealot, but I'm open for the idea to call forged commit
messages and forcing people to work as not good for any project like
this.
I've been working my ass off last sunday for the project. Partially trying to
identify regressions and to fix them. I tried to revert one change that was
logically wrong and introduced a regression. I got a -2 instantly which was
(allegedly) only set to give priority to the author's own unwritten patches.
There's a typo there /o\ I meant the "reviewer's own patches", author of the
-2 kind of. Sorry if this caused confusion.
I really appreciate that you are working hard to accomplish a more stable flashrom.
Thanks!
While aggravating, a -2 is not a personal attack,
I didn't see it like this and never meant to make the impression. I believe
there are situations where a -2 is justified and situations where it's bad
for everyone. When it's used to force people to work, I think that's in the
category of "this way of treating each other needs to stop".
and in this case I am pretty sure that it was an attempt to spark a conversation. I am fairly certain that I have seen similar behavior from you in the past (and I'm sure the other side was upset too ;).
Can you give an example? Well, obviously there was the -2 I gave in reaction
to the one I got here. But was there a case where I gave one without advice
or an alternative solution? Is there a way to search Gerrit for this? Would
really help me to reflect about it.
Nico, I also don't think that your code or reviews are the only ones that are infallible or that your work is worth significantly more than those of other folks in the community - and that applies as well to Edward and David and the others that are trying to create a working solution for Emmitsburg here.
Do you already see anything there that needs to stop? Or shall I continue to
describe what happened?
Trying to figure out your nuance here, but I'm listening.
Well, I have to admit this, giving priority to ones own patches, was my
strongest point and the question was rhetorical. There is a lot of hidden
work for reviewers on David's path and I felt forced to do it simply to
fix a regression.
David keeps calling things simple, but evidently that alone doesn't get
things done. Now I decided to just not do any work for him. If somebody
else does it, we'll see if it gets master to a sound state again; a gamble.
If not, master stays broken for the moment I guess.
To view, visit change 57589. To unsubscribe, or for help writing mail filters, visit settings.