From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mondschein.lichtvoll.de ([194.150.191.11]:56635 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933552AbcIOICj (ORCPT ); Thu, 15 Sep 2016 04:02:39 -0400 From: Martin Steigerwald To: Nicholas D Steeves Cc: "Austin S. Hemmelgarn" , Hugo Mills , Waxhead , linux-btrfs@vger.kernel.org Subject: Re: Is stability a joke? Date: Thu, 15 Sep 2016 10:02:33 +0200 Message-ID: <30721913.AYI27LRRDD@merkaba> In-Reply-To: <20160915010552.GC32452@DigitalMercury.dynalias.net> References: <57D51BF9.2010907@online.no> <20160915010552.GC32452@DigitalMercury.dynalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: Hello Nicholas. Am Mittwoch, 14. September 2016, 21:05:52 CEST schrieb Nicholas D Steeves: > On Mon, Sep 12, 2016 at 08:20:20AM -0400, Austin S. Hemmelgarn wrote: > > On 2016-09-11 09:02, Hugo Mills wrote: […] > > As far as documentation though, we [BTRFS] really do need to get our act > > together. It really doesn't look good to have most of the best > > documentation be in the distro's wikis instead of ours. I'm not trying to > > say the distros shouldn't be documenting BTRFS, but the point at which > > Debian (for example) has better documentation of the upstream version of > > BTRFS than the upstream project itself does, that starts to look bad. > > I would have loved to have this feature-to-stability list when I > started working on the Debian documentation! I started it because I > was saddened by number of horror story "adventures with btrfs" > articles and posts I had read about, combined with the perspective of > certain members within the Debian community that it was a toy fs. > > Are my contributions to that wiki of a high enough quality that I > can work on the upstream one? Do you think the broader btrfs > community is interested in citations and curated links to discussions? > > eg: if a company wants to use btrfs, they check the status page, see a > feature they want is still in the yellow zone of stabilisation, and > then follow the links to familiarise themselves with past discussions. > I imagine this would also help individuals or grad students more > quickly familiarise themselves with the available literature before > choosing a specific project. If regular updates from SUSE, STRATO, > Facebook, and Fujitsu are also publicly available the k.org wiki would > be a wonderful place to syndicate them! I definately think the quality of your contributions is high enough, others can also proofread and give in their experiences, so… By *all* means, go ahead *already*. It doesn´t fit all inside the table directly, I bet, *but* you can use footnotes or further explainations regarding features that need them with a headline per feature below the table and a link to it from within the table. Thank you! -- Martin