[opensuse-factory]

On Fri, Sep 2, 2016 at 8:27 PM, Jeff Mahoney wrote:

On 9/1/16 7:39 PM, Chris Murphy wrote:

...

On Thu, Sep 1, 2016 at 5:25 PM, Simon Lees wrote:

...

On 09/02/2016 07:47 AM, Chris Murphy wrote:

...

So please elucidate the list on exactly what code base you guys are using for quotas. If you're saying the warnings don't apply to your implementation then you guys are using something remarkably different and you need to tell us what that is or you do not get to sit there and claim this is a community project.

Given that the right people are probably sleeping or close too now, i'll remind you that you can look at openSUSE's kernel source code in the following locations.

https://build.opensuse.org/package/show/openSUSE:Leap:42.2/kernel-default https://github.com/openSUSE/kernel https://github.com/openSUSE/kernel-source

(Make sure you get the right branches for the git based one).

No, I'm not going to do that and it's inappropriate to even suggest it. The people who actually understand the code need to answer the question. They are the ones claiming their quota code is stable and production ready, the burden is on them to prove it, not for me to prove a negative. I'm not spending 1 f'n hour, let alone the likely 20 hours it would take me to look over hundreds to thousands of backports to find out what you guys have done, that compels you to claim your stuff is stable when upstream code is not there yet.

No, it's not. We publish the code for every single one of our kernels both in patch series and expanded tree form. Every maintenance update is tagged and even if they weren't, the last commit that was included in the RPM is included in the RPM metadata. We also have a very longstanding, public policy regarding code going upstream and a outsize percentage of our kernel teams in upstream maintainer roles. So you can imagine that when someone suggests that we're not being good community members with our kernels, it ruffles a few feathers. You're the one leveling an accusation (using typically incorrect assumptions). You bring the proof.

1. On the Btrfs mailing list, most every time anyone has a quota problem, they're informed if they need stable quota support to use XFS or ext4. And not a single Btrfs developer ever contradicts that advice in the slightest way. And this most recent non-contradicted advice happened just a few weeks ago. The very first time I have ever read anywhere, by any Btrfs developer, that enabling quotas is considered stable, was on this list. 2. https://github.com/kdave/btrfs-progs/commit/637c005ac881a7def923e3f56c9f9285... Upstream has performance and stability concerns in the current code. That commit is two weeks old. 3. There have been two attempts at quotas on Btrfs, which caused users all sorts of problems and were ultimately abandoned in favor of the current code base. Therefore my concern about quotas is not unfounded, is not unreasonable, and I'm not alone in that concern. I have explicitly invited having my assumptions contradicted, most notably at the very top of this email, and that was not the first time. Matthias, Richard, and some of your comments, while circumspect, can be inferred to mean your quota code substantially differs from the current stable kernel, and that's why you consider it stable. But then just yesterday you say "the only [Btrfs] patches we have applied to the 4.4-based SLE12-SP2/Leap kernel are backports and patches we've submitted upstream". I see that as an incongrucency with 1, 2, and 3. I cannot rectify the inconsistency with the available information. There are patches you've applied, that are not applied upstream, that wipe away the performance and stability concern in a barely two week old commit? OK... -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org