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