Bcachefs Publishes Patches For Disk Accounting Rewrite

[varikonniemi]

the stable issue? Greg is a professional, and didn't take the bait of kent's many digs. He understands that kent wants to submit a branch (as opposed to patches), and is willing to do that as long as that branch is made up properly. I didn't see any reference to IRC, but I may have missed it.

https://lore.kernel.org/stable/2ve257m37wusszvzkr254hp62nvxecmdcnybmft5ebl6n7hesj @yelqgrderuay/

> > Thanks, and let me know if there's any other workflow things I should
> > know about
>
> This is going to cause you more work, but less for us, so thanks!

per our conversation on IRC I'm going to write some simple tooling for
grepping through the git log for patches that may want to be backported
and haven't yet made it to a stable tree.

Also, Sasha, is there any reason your autosel tool couldn't be made
available for others to use that way?

Yes, it's more work for myself, but I have strong opinions that I as the
person who knows the code ought to be picking the patches to backport,
and doing the backports and resolving merge conflicts when necessary;
but collaborating on tooling would be _fantastic_.

and

> Hi stable team - please don't take patches for fs/bcachefs/ except from
> myself; I'll be doing backports and sending pull requests after stuff
> has been tested by my CI.

Now done:
https://git.kernel.org/pub/scm/linux...efdb6ebaee70db

greg k-h

[Weasel]

On this particular issue Kent isn't wrong to say that there needs to be a more web based workflow for kernel development.

Oh god fuck no.

[fitzie]

https://lore.kernel.org/stable/2ve257m37wusszvzkr254hp62nvxecmdcnybmft5ebl6n7hesj @yelqgrderuay/



and

> Hi stable team - please don't take patches for fs/bcachefs/ except from
> myself; I'll be doing backports and sending pull requests after stuff
> has been tested by my CI.

Now done:
https://git.kernel.org/pub/scm/linux...efdb6ebaee70db

greg k-h

both of those references were back in january, a month before the blow up. lore really needs a better frontend.

[varikonniemi]

both of those references were back in january, a month before the blow up. lore really needs a better frontend.

How is it possible then that kent gets upset with greg wrongly picking stable updates? When according to you it was already agreed only kent send stable updates?

[dralley]

Oh god fuck no.

It is endlessly funny to me that some people on this site fancy themselves defenders of the "true linux way" while kernel folks famous for their stubbornness are in fact far more open-minded.

https://lwn.net/Articles/952034/

The need for reviewer help in particular came up; Linus Torvalds jumped in to say that reviewing is boring, so it is unsurprising that people don't want to do it. He keeps seeing huge patch sets being sent out once each week with little seeming to happen with them. A few tweaks, perhaps, before the next version is sent, but no real resolution. What is really needed, he said, is to find ways to get away from the email patch model, which is not really working anymore. He feels that way now, even though he is "an old-school email person".

See also: Rust

[fitzie]

How is it possible then that kent gets upset with greg wrongly picking stable updates? When according to you it was already agreed only kent send stable updates?

first, the script to skip bcachefs broke, triggered by kent abusing commit tags. He literally committed "Fixes:" (with nothing after the colon). so it ended up pulling it in the patch. but that had nothing to do with why the stable submission failed. and when kent was told why his patches weren't included in the stable rc, he blamed them for not telling him, but they did tell him (all documented in a separate email thread).

But the bigger issue was that kent didnt' generate the stable patches correctly, which involves tying the patches to specific commits in linus's kernel git. That is a policy rule of stable, which says that what is in stable has already been included in linus tree (doesn't have to be identical, but it has to be directly related).

This annoyed kent in several ways. First was the fact that kent didn't know about "git cherry-pick -x" flag was a documentation issue. Second, kent thinks he as bcachefs maintainer should be able to send whatever he thinks is appropiate, and that's supersedes tying it to linus's repo. Third, kent disagreed with sending things as patches, and thinks stable it should be some dashboard git branch merge tool.

Kent' always getting emotional over technical disagreements is his biggest fault, but his habit on lashing out when he made a bad assumption or was ignorant of some process or technical detail is another big issue of his. the number of times people have explained something to him he didn't know will pretty much guarantee he will start ranting about documentation.

[gotar]

people have explained something to him he didn't know will pretty much guarantee he will start ranting about documentation.

Which is actually a good thing, as the documentation is the key factor in understanding your tools and most open source projects have deficiencies in this area.

For example, most of the kernel knowledge is available at best in maillist archives, when someone has noted something between dozens of other emails, and git is well know for it's un-documentation ("option foobar enables foo using bar"; just try to find explanation of what such basic idea as "index" is; difference between pull, fetch, checkout or 3 kind of reset, command option that completely changes this command behaviour etc.).

Such problems are being addressed eventually, but this often needs a prior push from such "rants".

Personally, I use code sources as a main reference for various tools on daily basis, but this is a huge waste of time...

[pWe00Iri3e7Z9lHOX2Qx]

I get the feeling we are a few years away from all the big "modern" features being in place (e.g. send / receive).

[geearf]

Am I the only one getting memories of Hans' discussions from Kent's?

[NotMine999]

Thanks for doing a deep dive on current kernel politics, i was only aware of the happenings on bcachefs mailing list i follow.

In the thread you linked the last messages seem to be that everyone is on the same page and understand each other after a IRC conversation, so it really just seems like people of different generations and communications styles being unable to communicate effectively in non-interactive format.

I would have said: "Thanks, but I will wait for the 5th sequel to the movie to come out sometime in the future."