| |
| ▲ | wavemode 4 days ago | parent | next [-] | | You still seem to be arguing that, shipping the change was the "right" thing to do. But that's not what's in dispute. Rather it is that, if what you think is right and what the person who makes the rules thinks is right are in disagreement, the adult thing to do is not to simply disregard the rules (and certainly not repeatedly, after being warned not to). This is the difference between being smart and being wise. If the goal of all this grandstanding was that, it's so incredibly and vitally important for these patches to get into the kernel, well guess what, now due to all this drama this part of the kernel is going to go unmaintained entirely. Is that good for the users? Did that help our stated goal in any way? No. | | |
| ▲ | charcircuit 4 days ago | parent [-] | | >the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster. | | |
| ▲ | nirava 4 days ago | parent | next [-] | | > The adult thing is to do best by the users Best by users in the long term is predictable processes. "RC = pure bug fixes" is a battle tested, dependable rule, absence of which causes chaos. > Critical file system bugs are worth blocking the release "Experimental" label EXACTLY to prevent this stuff from blocking release. Do you not know that bcachefs is experimental? This is an example of another rule which helps predictability. | | |
| ▲ | charcircuit 4 days ago | parent [-] | | This was a bug fix. My point is that there will always be bugs in the kernel so not all bugs are worth blocking a release, but losing data is worth blocking the release for. >"Experimental" label EXACTLY to prevent this stuff from blocking release In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label. | | |
| ▲ | dijksterhuis 3 days ago | parent | next [-] | | > In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label. alternative perspective: those users have knowingly and willingly put experimental software into production. it was their choice, they were informed of the risk and so the consequences and responsibility are their’s. it’s like signing up to take some experimental medicine, and then complaining no-one told me about the side-effect of persistent headaches. that doesn’t stop anyone from being user-centric in their approach, e.g. call me if you notice any symptoms and i’ll come round your house to examine you. … as long as everyone is clear about the fact it is experimental and the boundaries/limitations that apply, e.g. there will be certain persistent headache medicines that cannot be prescribed to you, or it might take longer for them to work because you’re on an experimental medicine. | | |
| ▲ | koverstreet 3 days ago | parent [-] | | Again: the elephant in the room is that a lot of bcachefs users are using it explicitly because they have lost a lot of data on btrfs, and they've found it to be more trustworthy. This puts us all in a shitty situation. I want the experimental label to come off at the right time - when every critical bug is fixed and it's as trustworthy as I can reasonably make it, when I know according to the data I have that everyone is going to have a good experience - but I have real users who need this thing and need to be supported. There is _no reason_ to interpret the experimental label in the way that you're saying, you're advocating that reliability for the end user be deprioritized versus every other filesystem. But deprioritizing reliability is what got us into this mess. | | |
| ▲ | rob_c 3 days ago | parent [-] | | >users are using it explicitly because they have lost a lot of data on btrfs PLEASE, honestly, EDUCATE THESE USERS. This is still marked experimental for numerous reasons regardless of the 'planned work for 6.18'. Users who can't suffer any data loss and are repeating their mistake of using btrfs shouldn't be using a none default/standard/hardened filesystem period. | | |
| ▲ | koverstreet 3 days ago | parent [-] | | No, really. People aren't losing data on bcachefs. We still have minor hiccups that do affect usability, and I put a lot of effort into educating users about where we're at and what to expect. In the past I've often told people who wanted to migrate off of btrfs "check back in six months", but I'm not now because 6.16 is looking amazingly solid; all the data I have says that your data really is safer on bcachefs than btrfs. I'm not advocating for people to jump from ext4/xfs/zfs, that needs more time. | | |
| ▲ | trueismywork 3 days ago | parent [-] | | You're arguing in circles. Either bcachefs is experimental and hence needs a lot of changes and tools to make sure that users dont lose data and hence the fixes are not critical/users can use a custom branch. Or it is stable and the only thing users need is actual big fixes. Not new tools in an RC3. Don't compare bcachefs with btrfs for stability. Compare it with ext4. (And dont care anecdotal data, compare the process). | | |
| ▲ | koverstreet 3 days ago | parent [-] | | So, are we agreeing that btrfs isn't fit for purpose, then? | | |
| ▲ | yencabulator 2 days ago | parent | next [-] | | Kent, whenever you're at a point where you could make a good decision and make progress on any non-technical axis, you choose to attack something or someone. This is why you're getting the reactions you are getting. bcachefs design looks good, literally everything else about the project is miserable, because of this. Now, I fully expect you to react poorly to this message, too. That is the expectation the world has formed of you. Think about that. | |
| ▲ | trueismywork 3 days ago | parent | prev [-] | | I don't understand your question. Are you going somewhere with this? |
|
|
|
|
|
| |
| ▲ | motorest 3 days ago | parent | prev [-] | | > This was a bug fix. I'm not sure exactly what you are talking about, and I'm not sure you do either. The discussion that preceded bcachefs to be dropped from the Linux kernel mainline involved an attempt to sneak a new features in RC, sidestepping testing and QA work, which was followed up by yet more egregious behavior from the mantainer. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur... | | |
| ▲ | charcircuit 3 days ago | parent [-] | | >sneak a new features in RC Too solve a bug with the filesystem that people in the wild were hitting. Like how Linus has said in the past with how there is a blurry line between security fixes and bug fixes. There is a blurry line between filesystem bugs and recovery features. If you read the email it is clear that the full feature has more work needed and this is more of a basic implementation to address bugs that people hit in the wild. | | |
| ▲ | motorest 3 days ago | parent [-] | | > Too solve a bug with the filesystem that people in the wild were hitting. So you acknowledge that this last episode involved trying to push new features into a RC. As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions. All these red flags were repeatedly raised in the mailing list by multiple kernel maintainers. Somehow you're ignoring all the feedback and warnings and complains raised by people from Linux kernel maintainers, and instead you've opted to try to gaslight the thread. | | |
| ▲ | koverstreet 3 days ago | parent [-] | | No, I'm sorry but you're simply wrong. bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after. I've explained my testing and QA on the lists multiple times. You, like the other kernel maintainers in that thread, are making wild assertions despite having no involvement with the project. | | |
| ▲ | majorchord 3 days ago | parent | next [-] | | As a rule, strong feelings about issues do not emerge from deep understanding. | |
| ▲ | motorest 3 days ago | parent | prev [-] | | > No, I'm sorry but you're simply wrong. It sounds like you have a hard time coping with reality. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur... I repeat: it sounds an awful lot like you are trying to gaslight this thread. Not cool. When this fact was again explicitly pointed out to you by Linus himself, you even tried to bullshit Linus and try to move the goalpost with absurd claims about how somehow it was ok to force untested and unreviewed features into a RC because somehow you know better about what users want or need as if it was some kind of justification for you to skip testing and proper release processes. You need to set aside some time for introspection because you sound like you are your own worst enemy. And those you interact with seem to be fed up and had enough of these stunts. | | |
| ▲ | koverstreet 3 days ago | parent [-] | | The changes weren't untested or unreviewed, and they've performed flawlessly on quite a few occasions since then. Sorry, the only person gaslighting here is you. |
|
|
|
|
|
|
| |
| ▲ | saubeidl 4 days ago | parent | prev [-] | | I don't think getting the FS kicked out of the kernel is best by the users. Good engineering requires long term thinking. | | |
| ▲ | procaryote 3 days ago | parent [-] | | There's more than bcachefs in the kernel. If dealing with bcachefs takes an inordinate amount of time and effort, dropping it is the right move. I don't know the situation well enought to review where they drew the line, but there definitely should be a line somewhere. | | |
|
|
| |
| ▲ | ranger_danger 3 days ago | parent | prev [-] | | [flagged] | | |
|
