Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bcachefs Goes to "Externally Maintained"

lwn.net

Post reply on HN
Print view View original

321–330 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#321

Post by koverstreet »

nullc wrote: post #244
koverstreet wrote: post #105

Earlier quoted context omitted.

When rules and authority start to take precedence over making sure things work, things have gone off the rails and we're not doing engineering anymore.

Collaborative projects don't work on pure engineering. There are significant resource management components that basically amount to therapy, psychiatry, and side show entertainment because the most critical resources are human minds. Excellent engineering management largely isolates engineers from having to deal with this non-engineering stuff (except for the subset that is specifically for their own personal benefi…

yes, which is why I've been saying for years the kernel community needs to get better at actual conflict resolution...

Re: Bcachefs Goes to "Externally Maintained"

#322

Post by p_l »

messe wrote: post #312
m-p-3 wrote: post #300

Earlier quoted context omitted.

Sure, but Oracle cannot retroactively relicense the code already published before then. The cat's already out of the bag, and as long as the code from before the fork is used according to the original license, it's legal.

I think you might have missed the point. Yes. Oracle have that copyright. That's the whole fucking point. Anything from before the fork is still licensed (and pretty much everything after) is still under the CDDL which is possibly in conflict with the GPL.

Oracle can't do anything. They can't relicense code that was already released as CDDL in any form other than what they did when they closed down Solaris.

The CDDL being unacceptable is the same issue that GPL3 or Apache is unacceptable - unlike GPLv2, CDDL mandates patent licensing as far as the code is considered.

Re: Bcachefs Goes to "Externally Maintained"

#323

Post by p_l »

chao- wrote: post #254
p_l wrote: post #212

Earlier quoted context omitted.

The legal issues between Linux kernel and ZFS are that Linux license does not allow incorporating licenses with more restrictions - including anything that puts protections against being sued for patented code contributed by license giver.

I am aware of that. I did a bad job phrasing my post, and it came off sounding more confident than I actually intended. I have two questions: (1) What are the expected consequences of a violation? (2) Why haven't any consequences occurred yet? My understanding is that Canonical is shipping ZFS with Ubuntu. Or do I misunderstand? Has Canonical not actually done the big, bad thing of distributing the Linux kernel with…

Oracle has no standing.

Additionally, GPLv2 does not prevent shipping ZFS combined with GPL code, because CDDL code is not derivative work of GPLv2 code. So it's legal to ship.

It could be problematic to upstream, because kernel development would demand streamlining to the point that the code would be derivative.

Additionally, two or three kernel contributors decided that the long standing consensus on derivative work is not correct and sued Canonical. So far nothing happened out of that, Los Alamos National Laboratory also laughed it off.

Re: Bcachefs Goes to "Externally Maintained"

#324

Post by koverstreet »

magicalhippo wrote: post #146
koverstreet wrote: post #133

Earlier quoted context omitted.

bcachefs has had active users, with real data that they want to protect, since before it was merged. A lot of the bcachefs users are using it explicitly because they've been burned by btrfs and need something more reliable. I am being much, much more conservative with removing the experimental label than past practice, but I have been very explicit that while it may not be perfect yet and users should expect some hic…

Given the bug fixes and changes, the experimental flag seems quite appropriate to me. That's not a bad thing. However, it was put in the kernel as experimental. That carries with it implications. As such, while it's very commendable that you wish to support the experimental bcachefs as-if it was production ready, you cannot reasonably impose that wish upon the rest of the kernel. That said I think you and your small…

All I need to support bcachefs is for the same rules to apply as they are to every other subsystem.

Re: Bcachefs Goes to "Externally Maintained"

#325

Post by koverstreet »

ajb wrote: post #318
aaronmdjones wrote: post #252

Earlier quoted context omitted.

As far as I know, the license incompatibility is on the GPL side of the equation. As in, shipping a kernel with the ZoL functionality is a violation of the GPL, not the CDDL. Thus, Oracle would not be able to sue Canonical (Edit: or, rather, have any reasonable expectation of winning this battle), as they have no standing. A copyright holder of some materially significant portion of the GPL code of the kernel would h…

Oracle do also make GPL'd contributions to the Linux kernel. So by that reasoning , they would have standing. It would be an interesting lawsuit as the judge might well ask why as copyright holder of ZFS they can't solve the problem they are suing over. But I think you underestimate the deviousness of oracle's legal dept.

If it ended up before Alsup we'd be fine.

Venue shopping being what it is, though...

Re: Bcachefs Goes to "Externally Maintained"

#326

Post by trueismywork »

koverstreet wrote: post #307
whatagreatboy wrote: post #288

Earlier quoted context omitted.

Was there any attempt at making rules for experimental features looser than other filesystems? That seems to be the biggest bottleneck here.

That does seem to be one of the big disconnects, yes. In the past I've argued that I do need a relatively free hand and to be able to move quickly, and explained my reasoning: we've been at the stage of stabilization where the userbase is fairly big, and when someone reports a bug we really need to work with them and fix it in a timely manner in order to keep them testing and reporting bugs. When someone learns the s…

I have seen your work and have some experience in kernel development. I think the situation is bad for everyone involved: you and linux. I would suggest trying to restart the conversation only focused on experimental feature changes.

In specific, I think there should be am effort to have a label (doesn't matter what one, hidden behind something like "icantbelieveitsnotbcachefs") where then you're (and not just you but anyone who wants to contribute changes to experimental features) allowed to push changes all the time.

That was already working for btrfs and will probably work for btrfs too.

Your argument about reducing feedback time can be a good argument in general. Yo shouldn't approach this as "im right allow me to push code, but start a different conversation about quick testing of experimental code with minimal friction. And make a case in general for linux to have this system.

Re: Bcachefs Goes to "Externally Maintained"

#327

Post by immibis »

koverstreet wrote: post #259
tuna74 wrote: post #220

Earlier quoted context omitted.

Linus T is responsible for everything in Linux, it is his project and he is the maintainer. He can do everything he wants in his branch and people just have to accept it. If you want to be responsible you have to fork Linux.

Let's examine this, shall we? Has he ever even been involved with a bcachefs bug? No, aside from arguing against shipping bugfixes. Has he contributed in any way, besides merging code? No... Has he set rules or guidelines that benefited bcachefs reliability? No, but he has shouted down talk about automated testing. I think you're confusing power with responsibility.

You're still doing that thing where you assume everyone else is you. Linus's job (some of which he delegates) is to take the contributions from ALL the hundreds of maintainers, and bundle it into a unified coherent whole. He is not only responsible for bcachefs reliability. In the train analogy I already used, he is the train driver, he is responsible for getting everyone who is on the train to their destination, but he is not responsible for ensuring that you're on the train. It's your responsibility to ensure that you're on the train when it departs.

You are one of those maintainers (not any more). Your code can be taken into the bundle (not any more), but on the bundle's schedule, not yours. You have consistently failed to understand that the train doesn't wait for you - if you are late, you get on the next one. If you don't want to get on the next one, then don't be late. Normal people, after missing a train once or twice, would adjust their schedule accordingly so they won't miss it next time. But your exclusive, repeated reaction has been to yell at the train driver and the station master, which is why you've been kicked out of the station.

Have you ever ridden a train, by the way? Were you on time? (Deutsche Bahn doesn't count because they're not on time)

Re: Bcachefs Goes to "Externally Maintained"

#328

Post by koverstreet »

immibis wrote: post #327
koverstreet wrote: post #259

Earlier quoted context omitted.

Let's examine this, shall we? Has he ever even been involved with a bcachefs bug? No, aside from arguing against shipping bugfixes. Has he contributed in any way, besides merging code? No... Has he set rules or guidelines that benefited bcachefs reliability? No, but he has shouted down talk about automated testing. I think you're confusing power with responsibility.

You're still doing that thing where you assume everyone else is you. Linus's job (some of which he delegates) is to take the contributions from ALL the hundreds of maintainers, and bundle it into a unified coherent whole. He is not only responsible for bcachefs reliability. In the train analogy I already used, he is the train driver, he is responsible for getting everyone who is on the train to their destination, but…

We're not talking about situations where the bcachefs changes could plausibly affect the rest of the kernel, and I am well known even within the kernel community for being on top of potential issues and responsive on bugs.

Re: Bcachefs Goes to "Externally Maintained"

#329

Post by isr »

bornfreddy wrote: post #65
sevg wrote: post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

Being an outsider to this whole scene, the whole thread reads very differently to me. Kent seems very patient in explaining his position (and frustrations arising from other people introducing bugs to his code) and the kernel & debian folks are performing a smearing campaign instead of replying to what I see are genuine problems in the process. As an example, the quotes that are referenced by user paravoid are, imho,…

To be honest, I somewhat agree. I'm sure there's a lot to this that us outsiders don't know (or honestly, for me, couldn't be bothered to know as there are far more important rabbit holes to spend time on).

However, sometimes, a certain detachment can help when looking at what is, in the end, a "cultural disagreement" more suited to an elementary school's playground.

Whenever I see open source spats like this, and then see a Dev harangued and chased from forum to forum by what looks like a coordinated group ("groupies"?), all accusing him/her of rude behaviour, while they keep making attacks on his/her personality, character or temperament...

it leads me to think rather poorly of this "wild west posse".

Anyway, bottom line, Kent is writing open source software to benefit others (and people didn't have qualms about taking his previous bcache & using it to build out storage solutions to make millions), so perhaps he doesn't quite deserve all the abuse and ganging up, no matter whose feathers he ruffled, and how.

Re: Bcachefs Goes to "Externally Maintained"

#330

Post by magicalhippo »

koverstreet wrote: post #324
magicalhippo wrote: post #146

Earlier quoted context omitted.

Given the bug fixes and changes, the experimental flag seems quite appropriate to me. That's not a bad thing. However, it was put in the kernel as experimental. That carries with it implications. As such, while it's very commendable that you wish to support the experimental bcachefs as-if it was production ready, you cannot reasonably impose that wish upon the rest of the kernel. That said I think you and your small…

All I need to support bcachefs is for the same rules to apply as they are to every other subsystem.

From what I have read and recall, the same rules do apply.

Rather, the disagreement seems to be over what constitutes a feature and what constitutes a bugfix.

As I recall, your view is that the repair code is part of the bugfix. However Linus deems it a feature, and thus applied the "no new features outside the merge window" rule.

I think Linus is correct here and you are wrong. New code made to repair flaws that previously could not be repaired is definitely a new feature of the repair tool.

On the other hand, I am sympathetic to your argument that this is after all an experimental filesystem which has different needs from a stable hardware driver say, and as I recall the repair tool changes were entirely contained in the bcachefs subtree. As such, the worst it could do was to fail compilation on certain platforms, which already happened previously.

Personally I would have dropped the bugfix vs feature debate and focused on trying to get Linus to allow the repair code in as a new feature. From what I recall Linus said, you already burned some goodwill by the previous kernel compilation failure, but perhaps Linus could change his stance if you worked with him.

Post reply on HN