Dear flashrom community,
I regret to tell you that I won't do any further upstream flashrom work in the foreseeable future. Compared to the last few months that won't change much, as I didn't spend as much time on flashrom as I wanted to.
TL;DR Maintaining flashrom was always a bit of a drag, mostly reviewing, organizing tests and releases, didn't leave much time for personal deve- lopment. Still, it was mostly fun. Until I flew too close to the sun and burned all my fuel that I had left for the project, trying to help converging the Chromium fork with upstream flashrom. I really hoped it wouldn't become another episode of "Nice! somebody else does the work". Not - a - chance.
Upfront
I was once told not to blame a company for the actions of individuals. However, there is forming a pattern, of people complaining to me how hard their job is; after I just did part of their job in my spare time! I don't think they are to blame, but they happen to all have the same employer. If we are pushed hard enough that we don't see anymore what we ask from one another, it's time to quit. At least regarding flash- rom I won't do any more work for them just because somebody said to be done in no time.
What happened
About half a year ago people started to push patches from Chromium upstream. I tried to welcome them and, as usual, to encouraged them to announce their plans on the mailing list so we could all work better together. Pipe dreams.
Obviously they wanted a fast lane, so the fork wouldn't cause too much more friction (for them!). No time to wait for other patches (including conflicting ones) to be reviewed. No [...] to do it by themselves. There was a decision to be made, either they would have to wait and rebase or other contributors would have to wait even longer and rebase. I chose wrong, and feel sorry about it. I prioritized the upstreaming, did fewer reviews for other contributors, let my own patches rot, didn't invest in further flashrom releases.
Around the same time, somebody (who happens to have administration rights) gave submit rights to the flashrom repository to one of them. I tried to stay calm and to be nice. (Edward, nothing personal, I actually was glad that it was you. I was just annoyed because of the way it happened, I had to dig up what is going on instead of reading it in a nice email.)
Up to now, I guess roughly 40~50 patches landed upstream. Most of them in one of these categories: o New features o Flash chip support o Remaining diff between the branches
The former turned out to be ok'ish, even though it's tedious to repeat every time that patches should be organized to ease review, and should have known issues fixed already.
The flash chip additions started with a weird idea, sort the `flashchips.c` on both sides to make it easier comparable. I didn't want to squabble about other people's workflow and, in good faith, allowed it.
The last category produced some odd patches with creative commit messages. It seems the idea was to diff individual files between the branches and if it was small enough to turn it into a commit. Now I have no idea how many sides their dice had that they used to decide which branch would be patched. The result was that I had to either complain about the commit message and hope to get answers (unlikely) or to dig into it by myself, spending hours staring at the history of the two branches to make some sense of it. I had to do exactly what the uploaders avoided to do because of their time constraints. Sometimes to find out that a commit effectively rever- ted good upstream work! If that wasn't discovered during review, that's the community's fault of course, and theirs to fix. The uploaders have no time; remember, their job is hard, yours is not.
Regrets
When I started maintaining flashrom, I set myself a rule: At least have a look at every patch that lands on Gerrit. I broke that rule at least with the patch train for AMD graphics cards, sorry Luc.
Obviously I regret prioritizing Chromium patches, before they proved to be valuable community members. My biggest regret is the re-sorting of `flashchips.c`. Given the few patches in that area that landed, it didn't pan out. Also, it was a pure convenience stunt, one can as well re-sort on-the-fly for comparison. OTOH, it breaks the Git history, making it much harder to check for reasons, e.g. why is this feature set? which variants of this chip were really tested?
If anybody wants to roll back master to fix that, you'd have my full support to make it happen without losing anything that was added after.
Legacy
I've left at least two of my patch trains rotting: A set to overhaul internal layout handling and one for IFWI layouts. I've seen that they were commented on eventually. Thank you Angel and David, and sorry in advance if I wasted your time in case the patches won't make it. The IFWI patches were written first, but they made me realize that layout changes are necessary and should come first. If I had spent more time on it, I would have rebased them accordingly.
Future
I'll have to maintain a flashrom branch for my employer. It might take some time before I rebase anything, but if anyone wants me to keep things published somewhere, I can arrange that.
For upstream, future's all up to you!
Thank you all for the time we spent together on the project! Nico
On Thu, Jan 30, 2020 at 03:16:59AM +0100, Nico Huber wrote:
I regret to tell you that I won't do any further upstream flashrom work in the foreseeable future. Compared to the last few months that won't change much, as I didn't spend as much time on flashrom as I wanted to.
Even with it being less time than you wanted, your work was and is appreciated! Thank you for maintaining flashrom during an important time for the project.
The uploaders have no time; remember, their job is hard, yours is not.
I'm really sorry that this is the impression that these interactions had on you. We might have taken your efforts for granted, and that's bad, indeed.
If anybody wants to roll back master to fix that, you'd have my full support to make it happen without losing anything that was added after.
Just for clarification what you're looking for here: rewrite public history to undo the commits that reorder the entries while leaving everything else intact?
To me that seems to be the only way to achieve the goal of preserving git history information on a line-by-line basis.
I can look into it (while putting current master on a separate branch name and making sure that pushes to the "wrong" branch don't make a mess in Gerrit.)
I've left at least two of my patch trains rotting: A set to overhaul internal layout handling and one for IFWI layouts. I've seen that they were commented on eventually. Thank you Angel and David, and sorry in advance if I wasted your time in case the patches won't make it. The IFWI patches were written first, but they made me realize that layout changes are necessary and should come first. If I had spent more time on it, I would have rebased them accordingly.
I'm curious: do you intend to work on them (e.g. on your employer's flashrom branch) or are these changes now effectively abandoned?
I'll have to maintain a flashrom branch for my employer. It might take some time before I rebase anything, but if anyone wants me to keep things published somewhere, I can arrange that.
Sounds good.
If you want that "somewhere" to be coreboot.org/flashrom.org we can certainly arrange that. If you prefer to put it somewhere outside the reach of us admins, I understand as well.
Tell me if I can help you with anything for this to happen.
For upstream, future's all up to you!
Again, thanks for your service, and I'm sorry for the troubles we put you through (I think part of the misguided re-sorting work was on me and probably other stuff as well.)
One parting question: anybody you'd want to nominate to succeed you in this position?
Regards, Patrick
On 30.01.20 10:17, Patrick Georgi wrote:
On Thu, Jan 30, 2020 at 03:16:59AM +0100, Nico Huber wrote:
If anybody wants to roll back master to fix that, you'd have my full support to make it happen without losing anything that was added after.
Just for clarification what you're looking for here: rewrite public history to undo the commits that reorder the entries while leaving everything else intact?
Yes, though I didn't mean to push it, just that I would still be willing to help with that. But /only if/ somebody else sees the need to act. I have my ways to work with Git, others have theirs, I don't know if anybody else looks as much into the Git history as I do. And the information is still preserved, it's just one more history step away.
Also, if somebody would decide to make bigger changes to the chip database in the future (putting it into a simpler, easier to parse format came up in the past), there'd be such a history cut anyway.
I've left at least two of my patch trains rotting: A set to overhaul internal layout handling and one for IFWI layouts. I've seen that they were commented on eventually. Thank you Angel and David, and sorry in advance if I wasted your time in case the patches won't make it. The IFWI patches were written first, but they made me realize that layout changes are necessary and should come first. If I had spent more time on it, I would have rebased them accordingly.
I'm curious: do you intend to work on them (e.g. on your employer's flashrom branch) or are these changes now effectively abandoned?
In theory I intend to work on them, but in practice we might be able to live with the current state of our branch for a few years. So there is no real incentive.
For upstream, future's all up to you!
Again, thanks for your service, and I'm sorry for the troubles we put you through (I think part of the misguided re-sorting work was on me and probably other stuff as well.)
Don't blame yourself. I know you downstreamed a lot upstream work, and made the branches easier to compare by that. If anything, you made my work easier that way. The re-sorting is on me, I knew the exact conse- quences when I let it in.
One parting question: anybody you'd want to nominate to succeed you in this position?
Hard to put a name here when it feels like deciding who is to be burned out next :) David is definitely the next most active maintainer and he knows his way around the project. If it wasn't for his support, I wouldn't have done the job in the first place. However, I fear he is as busy as any other senior developer. Remind me, why do we have day jobs again?
I tried to stop myself, but let me digress a little. I think it would be wise to convince Google to postpone their convergence efforts until they figured out how to produce sustainable software. I don't know the exact cause for the fork (maybe it was the lack of resources or the will to spend them) but I fear it might have rooted and not vanished. Throwing a bunch of developers -- that might only know the project in the way their employer deploys it -- at flashrom doesn't seem to work out. They won't care if they don't know what flashrom is about. This, convincing Google, is a burden that shouldn't fall to the people that try to main- tain flashrom in the future.
Nico
Hi Nico, Thanks again for all the work you've done! As others have said it's much appreciated.
I hope you'll find time to stay engaged. One thing I believe is frustrating to all of us is the state of paralysis that might be (at least partially) solved with better tools and automation. For example, I'd like to prioritize getting your manibuilder patches in, and I think things like the clang-format (CB:38208) can help reduce reviewer burden as well and make it easier for newcomers to produce commit-ready patches. We can also prioritize documentation (and move it into Git?) since I think a lot of time is spent on IRC and elsewhere helping people out with the same problems over and over again.
Hard to put a name here when it feels like deciding who is to be burned out next :)
No kidding! As CDH noted it's hard and not always rewarding.
We've never really had a BDFL, and most contributions are for specific hardware that a developer is concerned with so there's not much incentive to stay on the project for a long time.
David is definitely the next most active maintainer and he knows his way around the project. If it wasn't for his support, I wouldn't have done the job in the first place. However, I fear he is as busy as any other senior developer.
Indeed, I've been mostly absent for the last few months due to time constraints. Most of my recent activity has been focused on catching up on reviews (usually small ones, but larger ones too if I have time on a weekend or something) and responding to issues reported on Github.
I definitely plan to remain involved and am happy to help move things along wherever I can, but can't make a huge time commitment.
I don't know the exact cause for the fork (maybe it was the lack of resources or the will to spend them) but I fear it might have rooted and not vanished.
I can help shed some light on this. The original cause for the fork was due to EC vendors who didn't want certain things in publicly visible code. We eventually got all that code published - it turns out there's nothing really valuable from an IP perspective as far as flashrom functionality is concerned. Eventually Chromebooks started using their own open-source EC code which eliminated the problem, but by then things had diverged quite significantly and the project was in a similar state as it is now.
There have been efforts to minimize divergence, but they always ended up in a stalemate and patches were left to bitrot on Gerrit. Nobody's fault per se, it's just how things have played out as priorities and people have changed over the years.
Dear Nico,
thank you very much for your service. Being a maintainer is hard, and not always rewarding.
On 30.01.20 03:16, Nico Huber wrote:
Dear flashrom community,
I regret to tell you that I won't do any further upstream flashrom work in the foreseeable future. Compared to the last few months that won't change much, as I didn't spend as much time on flashrom as I wanted to.
[...] Future
I'll have to maintain a flashrom branch for my employer. It might take some time before I rebase anything, but if anyone wants me to keep things published somewhere, I can arrange that.
For upstream, future's all up to you!
Thank you all for the time we spent together on the project! Nico
It would be great if you could keep your branch published.
We will have to come up with a new maintainer. I will send an email to the list shortly about possible ways to proceed.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
David Hendricks -
Nico Huber -
Patrick Georgi