Announcement

Collapse
No announcement yet.

Bcachefs Squeezes Last Minute Feature Work Into Linux 6.8

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • fitzie
    replied
    Originally posted by fallingcats View Post

    If that's true the kernel team failed badly at naming, because that's widely known as a feature freeze. When someone has patches ready _inside the merge window_ then they're in time per definition. They shouldn't be called late and they should be called a dick for cutting it close either.
    yes, you can read linus explaining this here: https://lore.kernel.org/lkml/CAHk-=w...ail.gmail.com/

    Yes, the merge window is two weeks, but that's very much to allow me
    time to look things over, not "two weeks to hurriedly put together a
    branch that you send Linus on Friday of the second week". The whole
    "do an all-nighter to get the paper in the day before the dealine" is
    something that should have gone out the window after highschool. Not
    for kernel development.

    The rule is that things that get sent to me should be ready *before*
    the merge window opens, not be made ready during the merge window.
    With some slack for "life happens", of course, but I really get the
    feeling that a few people treat the end of the merge window as a
    deadline, missing the whole "it was supposed to be ready before the
    merge window".​

    Leave a comment:


  • fallingcats
    replied
    Originally posted by fitzie View Post

    this is just not the issue at all. linus isn't saying that kent skipped linux-next (which it turns out he did), he is saying that there is non-bug fixes being added to the bcachefs submission that were created after the merge window opened. the rule is pretty simple, all development targeting a kernel release should switch to bug fixes as soon as the merge window opens, and ideally days before the window opens so it has time to bake in linux-next.
    If that's true the kernel team failed badly at naming, because that's widely known as a feature freeze. When someone has patches ready _inside the merge window_ then they're in time per definition. They shouldn't be called late and they should be called a dick for cutting it close either.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by Raka555 View Post
    This guy has been working tirelessly for years on something that he is passionate about and that will benefit many people.

    I don't get why people are trying to point out flaws in his personality. None of us are perfect.

    Next time you are reporting on "his flaws", please state what you have done to make linux/opensource better for everyone...
    i rEpOrTeD An iSsUe!

    Leave a comment:


  • Raka555
    replied
    This guy has been working tirelessly for years on something that he is passionate about and that will benefit many people.

    I don't get why people are trying to point out flaws in his personality. None of us are perfect.

    Next time you are reporting on "his flaws", please state what you have done to make linux/opensource better for everyone...

    Leave a comment:


  • oleid
    replied
    Originally posted by varikonniemi View Post

    It's a side-effect of the Linux dev team wanting to minimize the intrusiveness of the bcachefs merge.
    I see, that makes sense, thanks.

    Leave a comment:


  • varikonniemi
    replied
    Originally posted by oleid View Post

    Amazing that the sorting algorithm lives inside the driver and not in some utility library😅
    It's a side-effect of the Linux dev team wanting to minimize the intrusiveness of the bcachefs merge.

    If you look at the comments, it looks like it will be moved out to common infrastructure, and if i'm not mistaken they look to fix several other in-baked implementations in other areas of the kernel by porting them over to the upcoming common implementation as well.
    Last edited by varikonniemi; 23 January 2024, 11:40 AM.

    Leave a comment:


  • oleid
    replied
    Originally posted by varikonniemi View Post
    sadly a recent 50% performance optimization did not make this release. https://lore.kernel.org/linux-bcache...ek5vmisbu/T/#t
    Amazing that the sorting algorithm lives inside the driver and not in some utility library😅

    Leave a comment:


  • Quackdoc
    replied
    for anyone who cares, since bcachefs made it into kernel 6.7, you should be able to easily just use a DKMS file now to pull the latest git changes, even if they don't make it for the window, I have a really basic pkgbuild script here for bcachefs-git, but it's largely "untested" since I don't actually follow the git changes so I don't know whats new but dkms reports it loaded, and modinfo does report it as dkms, so it should be fine? At the very least, someone who does follow the development of bcachefs should be able to check fairly easily

    various pkgbuildscripts. Contribute to Quackdoc/pkgbuild-scripts development by creating an account on GitHub.

    Leave a comment:


  • fitzie
    replied
    Originally posted by mdedetrich View Post

    Actually Kent did submit the changes into linux-next as is expected. The issue seems to stem from the fact that he submitted a big list of changes in last minute before merge window (and according to his latest response he seems to have misremembered when precisely that merge window was).

    Anyways this is all hot air.
    this is not in any way true and misses the point llnus made.

    Leave a comment:


  • fitzie
    replied
    Originally posted by stormcrow View Post
    If yall had actually bothered to look at the linux-next merge logs, you'd see Kent Overstreet did place them in the linux-next repository like he'd been asked to do. What Linus is miffed at is there are a lot of them all at once at practically the last minute in the merge cycle. It's not the first time he's taken someone to task for dumping a large or complex code dump at the last minute, unfortunately it won't be the last. Doing something like that violates the "don't be a dick" Thing even when he's 'technically correct'. (NO! 'Technically correct is the best correct' is just a very poor excuse for being a callous jerk, it's not the 'best kind of correct'!) Any competent boss that has to review submissions for his own deadline is going to be miffed at a subordinate dumping an unanticipated big load on him last minute. It's entirely correct for the boss to give the subordinate a talking to. No one functions in a vacuum. Practicing empathy for your collaborative partners isn't an option if you want to remain on their good side (and yes, Linus had to learn this, too.)
    this is just not the issue at all. linus isn't saying that kent skipped linux-next (which it turns out he did), he is saying that there is non-bug fixes being added to the bcachefs submission that were created after the merge window opened. the rule is pretty simple, all development targeting a kernel release should switch to bug fixes as soon as the merge window opens, and ideally days before the window opens so it has time to bake in linux-next.

    As for whether this stuff ever hit linux-next, let's take a look merge logs for linux-next, it seems not all of the patches kent submitted even made it into the the latest linux-next before he submitted them to linus. So even if that was the issue kent didn't follow any rules.

    linux next as of 2024-01-19 (last linux-next before window closed) https://lore.kernel.org/lkml/2024011...b.auug.org.au/

    * Merging bcachefs/for-next (1d1edd147cbd bcachefs: opts->compression can now also be applied in the background)

    linux next as of 2024-01-11 (linux-next 3 days after the window opened) https://lore.kernel.org/lkml/2024011...b.auug.org.au/

    * Merging bcachefs/for-next (169de41985f5 bcachefs: eytzinger0_find() search should be const)

    linux next as of 2024-01-22 (linux-next that finally includes all the patches) https://lore.kernel.org/lkml/2024012...uug.org.au/​

    Merging bcachefs/for-next (249f441f83c5 bcachefs: Improve inode_to_text())


    you can see all these commits on the tree he sent to linus to see what patches were not in linux-next when.





    Leave a comment:

Working...
X