On 3 September 2016 at 18:24, Chris Murphy
On Fri, Sep 2, 2016 at 8:27 PM, Jeff Mahoney
wrote: 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.
Well now you've seen at least one of our btrfs developers contradicting that advice. And it's not like Jeff is some novice who doesn't know what he's been talking about, he's been intimately involved with the kernel and explicitly btrfs and other filesystems for years now. He knows what he's talking about, he's very rarely wrong, and he is one of those boring "don't change anything, ship it only when it's absolutely ready" Enterprise developers. And even IF he is wrong, it's going to be the job of him and his team to fix it in both SLE and openSUSE, so you can take extra reassurance from that. And he works for SUSE, and SUSE has invested a lot of time, effort, engineering and testing on this. You've heard of the testing Jeff's team has done. In addition I can tell you that SUSE QA have been doing additional testing on btrfs qgroups and shaken out a corner case bug or two, but nothing that would classify as a 'Ship Stopper'. SUSE's Beta customers have all been using the feature also as part of the SLE 12 SP2 Open Beta programme. You've heard of the strategic importance of this feature from Matthias, SUSE's Senior Director of SLE Product Management. As a default option in our installation, almost all of SUSE's customers will be relying on this to work when they install SLE 12 SP2 at the end. SUSE isn't going to do that unless it's confident in the quality of the feature and its ability to support it for years. As an openSUSE contributor, you have an opportunity to contribute to this and to bring additional knowledge and data points to the table, but that comes with a responsibility to ensure that your data is accurate, correct, reproducible and actionable. By quoting random commits and mailinglist threads you do not have a full understanding of, while actively rejecting any suggestion to do your own testing, you have failed to contribute responsibly to this discussion.
The very first time I have ever read anywhere, by any Btrfs developer, that enabling quotas is considered stable, was on this list.
You heard it here first :)
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.
I will quote from that commit
"Signed-off-by: David Sterba
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".
4.4 is the latest upstream LTS Kernel 4.7 is the latest upstream kernel You have tested 4.7 in tumbleweed, and quoted from commits for 4.7 The current 4.4 Kernel contains many backports from 4.7. It also contains code which 4.7 has totally changed, so has specific fixes for 4.4 that are nothing to do with the current state in 4.7. These 4.4 backports+fixes number in the thousands. Many of them were written by SUSE engineers as part of their work for SLE 12 SP2/Leap 42.2 and then submitted upstream (it's our policy to submit all of our patches upstream). In the very unlikely event of upstream not accept a small amount of our patches, there is also the possibility that OUR 4.4 LTS Kernel might have some patches and configuration that differs from upstream vanilla 4.4 LTS. So, to put it bluntly, everything you tested in 4.7 is irrelevant unless you prove otherwise. everything you read about the current upstream development is not conclusive unless you prove otherwise. You were invited to help confirm the issues you feared were present in the 4.4 LTS Kernel used by Leap 42.2 or SLE 12 SP2. You were given advice from Jeff on how to do this. You have outright refused to do so, so frankly I feel you have no credibility to imply that there are deeper issues. To put it very directly, with all due respect, either contribute or shut up - this is a mailinglist for contributors to discuss the development of the openSUSE distributions, not a soap box for ill-informed rants. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org