<html><head></head><body>Since 3.5 is a feature release and we have a stable 3.4 I think blocking for documentation is quite sensible. Documentation is the #1 feature request from the community. <br><br><div class="gmail_quote">On April 15, 2014 12:12:22 AM PDT, Vijay Bellur <vbellur@redhat.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Thank you all for your efforts in arriving at better user documentation.<br /><br />Since we did not do a thorough job of blocking patches that did not have <br />adequate updates to the admin guide in the run upto 3.5.0, it certainly <br />seems difficult to get all admin-guide content ready in short<br />order. Hence I think it might be prudent to treat the documentation bugs <br />as blockers for 3.5.1. There is documentation for most features <br />mentioned in the bugs in some form (git commit messages, feature pages, <br />blog posts) etc.It might be a good idea to consolidate all such links in <br />one place.<br /><br />My preference would be to release 3.5.0 and ensure that our admin guide <br />is ready in terms of content by 3.5.1.<br /><br />Regards,<br />Vijay<br /><br />On 04/11/2014 06:40 AM, John Mark Walker wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Thank you,
guys, for taking this on. The community will greatly benefit from this effort.<br /><br /> -JM<br /><br /><br /> ----- Original Message -----<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On Thu, Apr 10, 2014 at 11:47:08PM +0530, Lalatendu Mohanty wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> On 04/10/2014 11:20 PM, Justin Clift wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> Note, the docs go in the /doc directory in the git repo, both 3.5 and<br /> master branches. ;)<br /><br /> When submitting patches to gerrit, feel free to reuse the bug-xxxx<br /> branch that was used for the code submission, or even use the 3.5.0<br /> tracker bug (1049981).<br /></blockquote><br /> Here is the documentation about "how to send documentation patch"
:<br /> <a href="http://www.gluster.org/community/documentation/index.php/Submitting_Documentation_Patches">http://www.gluster.org/community/documentation/index.php/Submitting_Documentation_Patches</a><br /></blockquote><br /> Lala and I have been busy filing bugs for all of the features that are<br /> listed in the email below as having missing documentation:<br /> - <a href="https://bugzilla.redhat.com/showdependencytree.cgi?id=1049981">https://bugzilla.redhat.com/showdependencytree.cgi?id=1049981</a><br /><br /> All the bugs that are *not* in POST or MODIFIED state need to file<br /> patches. The ones that are in POST could probably benefit from reviews<br /> in Gerrit (see the respective bug for details).<br /><br /> Note that these bugs need patches submitted against the release-3.5<br /> branch, as well as the master branch. We do not want documentation lost<br /> with future releases.<br /><br /> If you have any questions, please let us know by replying to this email,<br />
or talk to us in #gluster-dev on Freenode.<br /><br /> Thanks,<br /> Niels<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> + Justin<br /><br /> On 10/04/2014, at 6:21 PM, Justin Clift wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> Hi all,<br /><br /> These are the features in Gluster 3.5 still needing documentation:<br /><br /> * AFR CLI enhancements<br /> * Exposing Volume Capabilities <- only if this made it in, which I can't<br /> see atm<br /> * File Snapshots in GlusterFS<br /> * gfid-access<br /> * On-Wire Compression/Decompression<br /> * Preventing NFS restart on volume change<br /> * Quota Scalability<br /> * readdir-ahead<br /> * zerofill API for GlusterFS<br /> * Brick Failure
Detection<br /> * Disk Encryption<br /> * Changelog based parallel geo-replication<br /> * Improved block device translator<br /> * Remove brick CLI change<br /> * RDMA-connection manager (RDMA-CM)<br /> * Support for NUFA translator<br /> * Distributed Geo-Replication<br /><br /> These are the features added in Gluster 3.4, still needing documentation:<br /><br /> * Write Once Read Many (WORM) volume<br /> * BD Xlator - Block Device translator<br /> * Duplicate Request Cache (DRC)<br /> * Server-Quorum<br /> * Libgfapi<br /> * Eager locking<br /> * oVirt 3.2 integration<br /> * qemu 1.3 - libgfapi integration<br /> * Access Control List - Version 3 support for Gluster NFS<br /><br /><br /> All of the required documentation is *end user focused*, which includes<br /> three parts:<br /><br /> a) Description of what a feature does, so a user knows if it's something<br /> they'd want to use or try<br /><br /> b) Exact steps on setting it up, and full list of parameters that can<br
/> affect<br /> it. For example:<br /><br /> * CLI parameters (if it has them)<br /> * Volume options/parameters (if it has them)<br /> * Dependencies, (eg on other features, external programs,<br /> etc)<br /><br /> c) A fully worked example. Step by step commands with comments are<br /> optimal.<br /><br /> A good way to start is by doing the setup/configuration for the feature<br /> in your<br /> local environment, starting from a new, un-configured installation.<br /> Ensure your<br /> terminal program has a lot of scroll back buffer available. :)<br /><br /> After the environment is fully configured, cut-n-paste the scroll back<br /> buffer<br /> into a text mode document editor somewhere (or an etherpad). Then go<br /> through<br /> it, removing everything except the needed commands and any useful output.<br /><br /> Then go through it a 2nd time, adding line feeds and headings, spacing<br /> things<br /> out visually for clarity, and adding
comments to describe what's going on<br /> and<br /> why it's being done.<br /><br /> This becomes the c) in the list above. With that in place, it's<br /> generally<br /> pretty straight forward to next make the b) part, and then finishing off<br /> with<br /> a full feature description appropriate for end users (if it hasn't<br /> spontaneously come to mind already).<br /><br /> The text format we're using is AsciiDoc. Quick Reference here:<br /><br /> <a href="http://asciidoctor.org/docs/asciidoc-syntax-quick-reference">http://asciidoctor.org/docs/asciidoc-syntax-quick-reference</a>/<br /><br /> :)<br /><br /> Regards and best wishes,<br /><br /> Justin Clift<br /><br /> --<br /></blockquote></blockquote></blockquote></blockquote></blockquote><br /><br /><hr /><br />Gluster-devel mailing list<br />Gluster-devel@nongnu.org<br /><a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br
/></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>