summaryrefslogtreecommitdiffstats
path: root/doc/developer-guide
diff options
context:
space:
mode:
authorBipin Kunal <bkunal@redhat.com>2015-11-13 19:19:17 +0530
committerHumble Devassy Chirammal <humble.devassy@gmail.com>2015-11-15 05:19:37 -0800
commit4af4c1acc7b77d70af1b09964c7cbddb5c797214 (patch)
tree07fda1a3b4fcbd395e63f25f85058144e0280415 /doc/developer-guide
parentb7b13c73369a3cb237de16d58425b63640c6f33e (diff)
docs: move contributor docs to the glusterdocs repository
* Moved few files to glusterdocs repo * Files were moved in pull requests given below: https://github.com/gluster/glusterdocs/pull/60 https://github.com/gluster/glusterdocs/pull/62 * This patch removes file from this repo which were moved to glusterdocs repo Change-Id: I6e529911e0be66b261961c44bcdbe361aafa2886 BUG: 1206539 Signed-off-by: Bipin Kunal <bkunal@redhat.com> Reviewed-on: http://review.gluster.org/12576 Reviewed-by: Niels de Vos <ndevos@redhat.com> Tested-by: NetBSD Build System <jenkins@build.gluster.org> Tested-by: Gluster Build System <jenkins@build.gluster.com>
Diffstat (limited to 'doc/developer-guide')
-rw-r--r--doc/developer-guide/Backport-Guidelines.md41
-rw-r--r--doc/developer-guide/Backport-Wishlist.md193
-rw-r--r--doc/developer-guide/Bug-Reporting-Guidelines.md128
-rw-r--r--doc/developer-guide/Bug-Triage.md400
-rw-r--r--doc/developer-guide/Bug-report-Life-Cycle.md57
-rw-r--r--doc/developer-guide/Bug-reporting-template.md55
-rw-r--r--doc/developer-guide/Building GlusterFS.md147
-rw-r--r--doc/developer-guide/Compiling-RPMS.md178
-rw-r--r--doc/developer-guide/Developers-Index.md54
-rw-r--r--doc/developer-guide/Development-Workflow.md457
-rw-r--r--doc/developer-guide/Easy-Fix-Bugs.md35
-rw-r--r--doc/developer-guide/Fixing-issues-reported-by-tools-for-static-code-analysis.md66
-rw-r--r--doc/developer-guide/GlusterFS-Release-process.md73
-rw-r--r--doc/developer-guide/Guidelines-For-Maintainers.md70
-rw-r--r--doc/developer-guide/Jenkins-Infrastructure.md127
-rw-r--r--doc/developer-guide/Jenkins-Manual-Setup.md146
-rw-r--r--doc/developer-guide/Projects.md99
-rw-r--r--doc/developer-guide/Simplified-Development-Workflow.md238
18 files changed, 0 insertions, 2564 deletions
diff --git a/doc/developer-guide/Backport-Guidelines.md b/doc/developer-guide/Backport-Guidelines.md
deleted file mode 100644
index af48dc0..0000000
--- a/doc/developer-guide/Backport-Guidelines.md
+++ /dev/null
@@ -1,41 +0,0 @@
-Bugs often get fixed in master before release branches. When a bug is
-fixed in the master branch, it might be desirable or necessary in a
-stable branch. To put the fix in stable branch we need to backport the
-fix to stable branch.
-
-Anyone in the community can suggest a backport. If you are interested to
-suggest a backport, please check the [Backport
-Wishlist](./Backport Wishlist.md).
-
-This page describes the steps needed to backport simple changes. Changes
-that do not apply cleanly will need some manual modifications and using
-`git cherry-pick` may not always be the easiest solution.
-
-1. Git clone the GlusterFS code
-
- git clone ssh://username@review.gluster.org/glusterfs
-
-2. Create and checkout a new branch for your work, based on the branch
- for the backport version
-
- git checkout -t -b bug-123456/release-3.5 origin/release-3.5
-
-3. Cherry pick the change from master.
-
- $ git cherry-pick -x a0b1c2d3e4f5
- - verify that the change has been merged in the master branch.
-
-4. Update/correct the commit message.
-
- $ git commit -s --amend --date="$(date)"
-[This is one example](https://github.com/gluster/glusterfs/commit/40407afb529f6e5fa2f79e9778c2f527122d75eb) of the commit message that has a good description for a backport. Notice the indention of the patch-metadata like BUG, Change-ID and Reviewed-on tags. There is also the original commit-id that was cherry picked from the master branch.
- -make sure to quote the review tags
- -update the BUG reference, point to the BUG that is used for this
-particular release-branch
- -add a Signed-off-by tag
-
-5. Run `./rfc.sh` to post the backport for review.
-
- ./rfc.sh
-After submitting patch(es), make sure to move the bug to the *POST*
-status.
diff --git a/doc/developer-guide/Backport-Wishlist.md b/doc/developer-guide/Backport-Wishlist.md
deleted file mode 100644
index f191820..0000000
--- a/doc/developer-guide/Backport-Wishlist.md
+++ /dev/null
@@ -1,193 +0,0 @@
-Bugs often get fixed in master before release branches.
-
-When a bug is fixed in the master branch it might be desirable or
-necessary to backport the fix to a stable branch.
-
-This page is intended to help organize support (and prioritization) for
-backporting bug fixes of importance to the community.
-
-### GlusterFs 3.6
-
-Requested Backports for 3.6.0
------------------------------
-
-The tracker bug for 3.6.0 :
-<https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.6.0>
-
-Please add 'glusterfs-3.6.0' in the 'Blocks' field of bugs to propose
-inclusion in GlusterFS 3.6.0.
-
-### GlusterFs 3.5
-
-Requested Backports for 3.5.3
------------------------------
-
-Current [list of bugs planned for
-inclusion](https://bugzilla.redhat.com/showdependencytree.cgi?hide_resolved=0&id=glusterfs-3.5.3).
-
-- File a new bug for backporting a patch to 3.5.3:
- [<https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS&blocked=glusterfs-3.5.3&version=3.5.2&short_desc=backport%20request%20for%20>...
- new glusterfs-3.5.3 backport request]
-
-### GlusterFs 3.4
-
-Requested Backports for 3.4.6
------------------------------
-
-The tracker bug for 3.4.6 :
-<https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.4.6>
-
-Please add 'glusterfs-3.4.6' in the 'Blocks' field of bugs to propose
-inclusion in GlusterFS 3.4.6.
-
-<https://bugzilla.redhat.com:443/show_bug.cgi?id=1116150>
-<https://bugzilla.redhat.com:443/show_bug.cgi?id=1117851>
-
-Requested Backports for 3.4.4
------------------------------
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=859581> - "self-heal
-process can sometimes create directories instead of symlinks for the
-root gfid file in .glusterfs"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=1041109> - "structure needs
-cleaning" message appear when accessing files.
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=1073023> - glusterfs mount
-crash after remove brick, detach peer and termination
-
-Requested Backports for 3.4.3
------------------------------
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=859581> - "self-heal
-process can sometimes create directories instead of symlinks for the
-root gfid file in .glusterfs"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=1041109> - "structure needs
-cleaning" message appear when accessing files.
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=977492> - large NFS writes
-to Gluster slow down then stop
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=1073023> - glusterfs mount
-crash after remove brick, detach peer and termination
-
-Requested Backports for 3.3.3
------------------------------
-
-[Enable fusermount by default, make nightly autobuilding
-work](https://bugzilla.redhat.com/1058666)
-
-Requested Backports for 3.4.2
------------------------------
-
-Please enter bugzilla ID or patch URL here:
-
-​1) Until RDMA handling is improved, we should output a warning when
-using RDMA volumes -
-<https://bugzilla.redhat.com/show_bug.cgi?id=1017176>
-
-​2) Unable to shrink volumes without dataloss -
-<https://bugzilla.redhat.com/show_bug.cgi?id=1024369>
-
-​3) cluster/dht: Allow non-local clients to function with nufa volumes.
-- <http://review.gluster.org/5414>
-
-Requested Backports for 3.4.1
------------------------------
-
-Please enter bugzilla ID or patch URL here.
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=812230> - "quota context
-not set in inode"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=893778> - "NFS crash bug"
-
-A note for whoever reviews this list: These are the fixes for issues
-that have caused actual service disruption in our production
-installation and thus are absolutely required for us (-- Lubomir
-Rintel):
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=994392> - "Setting ACL
-entries fails with glusterfs-3.4.0"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=991622> - "fd leaks
-observed while running dbench with "open-behind" volume option set to
-"on" on a replicate volume"
-
-These are issues that we've stumbled upon during the git log review and
-that seemed scary enough for us to cherry-pick them to avoid risk,
-despite not being actually hit. Hope that helps deciding whether it's
-worthwhile cherry-picking them (-- Lubomir Rintel):
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=961691> "CLI crash upon
-executing "gluster peer status" command"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=965995> "quick-read and
-open-behind xlator: Make options (volume\_options ) structure NULL
-terminated."
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=958691> "nfs-root-squash:
-rename creates a file on a file residing inside a sticky bit set
-directory"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=982919> "DHT : files are
-stored on directory which doesn't have hash range(hash layout)"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=976189> "statedump crashes
-in ioc\_inode\_dump"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=982174> "cli crashes when
-setting diagnostics.client-log-level is set to trace"
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=989579> "glusterfsd crashes
-on smallfile benchmark"
-
-<http://review.gluster.org/5821>, "tests: call 'cleanup' at the end of
-each test", <https://bugzilla.redhat.com/show_bug.cgi?id=1004756>,
-backport of 983975
-
-<http://review.gluster.org/5822>, "glusterfs-api.pc.in contains an
-rpath", <https://bugzilla.redhat.com/show_bug.cgi?id=1004751>, backport
-of 1002220
-
-<http://review.gluster.org/5824> "glusterd.service (systemd), ensure
-glusterd starts before any local gluster mounts",
-<https://bugzilla.redhat.com/show_bug.cgi?id=1004796>, backport of
-1004795
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=819130> meta, check that
-glusterfs.spec.in has all relevant updates
-
-<https://bugzilla.redhat.com/show_bug.cgi?id=1012400> - Glusterd would
-not store all the volumes when a global options were set leading to peer
-rejection
-
-Requested Backports
--------------------
-
-- Please backport [gfapi: Closed the logfile fd and initialize to NULL
- in glfs\_fini](http://review.gluster.org/#/c/6552) into release-3.5
- - Done
-- Please backport [cluster/dht: Make sure loc has
- gfid](http://review.gluster.org/5178) into release-3.4
-- Please backport [Bug 887098](http://goo.gl/QjeMP) into release-3.3
- (FyreFoX) - Done
-- Please backport [Bug 856341](http://goo.gl/9cGAC) into release-3.2
- and release-3.3 (the-me o/b/o Debian) - Done for release-3.3
-- Please backport [Bug 895656](http://goo.gl/ZNs3J) into release-3.2
- and release-3.3 (semiosis, x4rlos) - Done for release-3.3
-- Please backport [Bug 918437](http://goo.gl/1QRyw) into release-3.3
- (tjstansell) - Done
-- Please backport into [Bug
- 884597](https://bugzilla.redhat.com/show_bug.cgi?id=884597)
- release-3.3 (nocko) - Done
-
-Unaddressed bugs
-----------------
-
-- [Bug 838784](https://bugzilla.redhat.com/show_bug.cgi?id=838784)
-- [Bug 893778](https://bugzilla.redhat.com/show_bug.cgi?id=893778)
-- [Bug 913699](https://bugzilla.redhat.com/show_bug.cgi?id=913699);
- possibly related to [Bug
- 884597](https://bugzilla.redhat.com/show_bug.cgi?id=884597) \ No newline at end of file
diff --git a/doc/developer-guide/Bug-Reporting-Guidelines.md b/doc/developer-guide/Bug-Reporting-Guidelines.md
deleted file mode 100644
index d03878a..0000000
--- a/doc/developer-guide/Bug-Reporting-Guidelines.md
+++ /dev/null
@@ -1,128 +0,0 @@
-Before filing a bug
--------------------
-
-If you are finding any issues, these preliminary checks as useful:
-
-- Is SELinux enabled? (you can use `getenforce` to check)
-- Are iptables rules blocking any data traffic? (`iptables -L` can
- help check)
-- Are all the nodes reachable from each other? [ Network problem ]
-- Please search Bugzilla to see if the bug has already been reported
- - Choose GlusterFS as the "product", and then type something
- relevant in the "words" box. If you are seeing a crash or abort,
- searching for part of the abort message might be effective. If
- you are feeling adventurous you can select the "Advanced search"
- tab; this gives a lot more control but isn't much better for
- finding existing bugs.
- - If a bug has been already filed for a particular release and you
- found the bug in another release,
- - please clone the existing bug for the release, you found the
- issue.
- - If the existing bug is against mainline and you found the
- issue for a release, then the cloned bug *depends on* should
- be set to the BZ for mainline bug.
-
-Anyone can search in Bugzilla, you don't need an account. Searching
-requires some effort, but helps avoid duplicates, and you may find that
-your problem has already been solved.
-
-Reporting A Bug
----------------
-
-- You should have a Bugzilla account
-- Here is the link to file a bug:
- [Bugzilla](https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS)
-- The template for filing a bug can be found [
- *here*](./Bug reporting template.md)
-
-*Note: Please go through all below sections to understand what
-information we need to put in a bug. So it will help the developer to
-root cause and fix it*
-
-### Required Information
-
-You should gather the information below before creating the bug report.
-
-#### Package Information
-
-- Location from which the packages are used
-- Package Info - version of glusterfs package installed
-
-#### Cluster Information
-
-- Number of nodes in the cluster
-- Hostnames and IPs of the gluster Node [if it is not a security
- issue]
- - Hostname / IP will help developers in understanding &
- correlating with the logs
-- Output of `gluster peer status`
-- Node IP, from which the "x" operation is done
- - "x" here means any operation that causes the issue
-
-#### Volume Information
-
-- Number of volumes
-- Volume Names
-- Volume on which the particular issue is seen [ if applicable ]
-- Type of volumes
-- Volume options if available
-- Output of `gluster volume info`
-- Output of `gluster volume status`
-- Get the statedump of the volume with the problem
-
-`   $ gluster volume statedump `<vol-name>
-
-This dumps statedump per brick process in `/var/run/gluster`
-
-*NOTE: Collect statedumps from one gluster Node in a directory.*
-
-Repeat it in all Nodes containing the bricks of the volume. All the so
-collected directories could be archived,compressed and attached to bug
-
-#### Brick Information
-
-- xfs options when brick partition was done
- - This could be obtained with this command :
-
-`   $ xfs_info /dev/mapper/vg1-brick`
-
-- Extended attributes on the bricks
- - This could be obtained with this command:
-
-`   $ getfattr -d -m. -ehex /rhs/brick1/b1`
-
-#### Client Information
-
-- OS Type ( Windows, RHEL )
-- OS Version : In case of Linux distro get the following :
-
-`   $ uname -r`\
-`   $ cat /etc/issue`
-
-- Fuse or NFS Mount point on the client with output of mount commands
-- Output of `df -Th` command
-
-#### Tool Information
-
-- If any tools are used for testing, provide the info/version about it
-- if any IO is simulated using a script, provide the script
-
-#### Logs Information
-
-- You can check logs for check for issues/warnings/errors.
- - Self-heal logs
- - Rebalance logs
- - Glusterd logs
- - Brick logs
- - NFS logs (if applicable)
- - Samba logs (if applicable)
- - Client mount log
-- Add the entire logs as attachment, if its very large to paste as a
- comment
-
-#### SOS report for CentOS/Fedora
-
-- Get the sosreport from the involved gluster Node and Client [ in
- case of CentOS /Fedora ]
-- Add a meaningful name/IP to the sosreport, by renaming/adding
- hostname/ip to the sosreport name
diff --git a/doc/developer-guide/Bug-Triage.md b/doc/developer-guide/Bug-Triage.md
deleted file mode 100644
index bcd475e..0000000
--- a/doc/developer-guide/Bug-Triage.md
+++ /dev/null
@@ -1,400 +0,0 @@
-Bug Triage Guidelines
-=====================
-
-- Triaging of bugs is an important task; when done correctly, it can
- reduce the time between reporting a bug and the availability of a
- fix enormously.
-
-- Triager should focus on new bugs, and try to define the problem
- easily understandable and as accurate as possible. The goal of the
- triagers is to reduce the time that developers need to solve the bug
- report.
-
-- A triager is like an assistant that helps with the information
- gathering and possibly the debugging of a new bug report. Because a
- triager helps preparing a bug before a developer gets involved, it
- can be a very nice role for new community members that are
- interested in technical aspects of the software.
-
-- Triagers will stumble upon many different kind of issues, ranging
- from reports about spelling mistakes, or unclear log messages to
- memory leaks causing crashes or performance issues in environments
- with several hundred storage servers.
-
-Nobody expects that triagers can prepare all bug reports. Therefore most
-developers will be able to assist the triagers, answer questions and
-suggest approaches to debug and data to gather. Over time, triagers get
-more experienced and will rely less on developers.
-
-**Bug triage can be summarised as below points:**
-
-- Is there enough information in the bug description?
-- Is it a duplicate bug?
-- Is it assigned to correct component of GlusterFS?
-- Are the Bugzilla fields correct?
-- Is the bug summary is correct?
-- Assigning bugs or Adding people to the "CC" list
-- Fix the Severity And Priority.
-- Todo, If the bug present in multiple GlusterFS versions.
-- Add appropriate Keywords to bug.
-
-The detailed discussion about the above points are below.
-
-Weekly meeting about Bug Triaging
----------------------------------
-
-We try to meet every week in \#gluster-meeting on Freenode. The meeting
-date and time for the next meeting is normally updated in the
-[agenda](https://public.pad.fsfe.org/p/gluster-bug-triage).
-
-Getting Started: Find reports to triage
----------------------------------------
-
-There are many different techniques and approaches to find reports to
-triage. One easy way is to use these pre-defined Bugzilla reports (a
-report is completely structured in the URL and can manually be
-modified):
-
-- New **bugs** that do not have the 'Triaged' keyword [Bugzilla
- link](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=keywords&keywords=Triaged%2CFutureFeature&keywords_type=nowords&list_id=3014117&o1=nowords&product=GlusterFS&query_format=advanced&v1=Triaged)
-- New **features** that do not have the 'Triaged' keyword (identified
- by FutureFeature keyword, probably of interest only to project
- leaders) [Bugzilla
- link](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=keywords&f2=keywords&list_id=3014699&o1=nowords&o2=allwords&product=GlusterFS&query_format=advanced&v1=Triaged&v2=FutureFeature)
-- New glusterd bugs: [Bugzilla
- link](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&o1=nowords&v1=Triaged&component=glusterd)
-- New Replication(afr) bugs: [Bugzilla
- link](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=replicate&f1=keywords&list_id=2816133&o1=nowords&product=GlusterFS&query_format=advanced&v1=Triaged)
-- New distribute(DHT) bugs: [Bugzilla
- links](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=distribute&f1=keywords&list_id=2816148&o1=nowords&product=GlusterFS&query_format=advanced&v1=Triaged)
-
-- New bugs against version 3.6:
- [<https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&f2=version&o1=nowords&o2=regexp&v1=Triaged&v2>=\^3.6
- Bugzilla link]
-- New bugs against version 3.5:
- [<https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&f2=version&o1=nowords&o2=regexp&v1=Triaged&v2>=\^3.5
- Bugzilla link]
-- New bugs against version 3.4:
- [<https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&f2=version&o1=nowords&o2=regexp&v1=Triaged&v2>=\^3.4
- Bugzilla link]
-
-- [<https://bugzilla.redhat.com/page.cgi?id=browse.html&product=GlusterFS&product_version>=&bug\_status=all&tab=recents
- bugzilla tracker] (can include already Triaged bugs)
-
-- [Untriaged NetBSD
- bugs](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=Triaged&keywords_type=nowords&op_sys=NetBSD&product=GlusterFS)
-- [Untriaged FreeBSD
- bugs](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=Triaged&keywords_type=nowords&op_sys=FreeBSD&product=GlusterFS)
-- [Untriaged Mac OS
- bugs](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=Triaged&keywords_type=nowords&op_sys=Mac%20OS&product=GlusterFS)
-
-In addition to manually checking Bugzilla for bugs to triage, it is also
-possible to receive emails when new
-bugs are filed or existing bugs get updated.
-
-If at any point you feel like you do not know what to do with a certain
-report, please first ask [irc or mailing
-lists](http://www.gluster.org/community/index.html) before changing
-something.
-
-Is there enough information?
-----------------------------
-
-To make a report useful, the same rules apply as for
-[bug reporting guidelines](./Bug Reporting Guidelines.md).
-
-It's hard to generalize what makes a good report. For "average"
-reporters is definitely often helpful to have good steps to reproduce,
-GlusterFS software version , and information about the test/production
-environment, Linux/GNU distribution.
-
-If the reporter is a developer, steps to reproduce can sometimes be
-omitted as context is obvious. *However, this can create a problem for
-contributors that need to find their way, hence it is strongly advised
-to list the steps to reproduce an issue.*
-
-Other tips:
-
-- There should be only one issue per report. Try not to mix related or
- similar looking bugs per report.
-
-- It should be possible to call the described problem fixed at some
- point. "Improve the documentation" or "It runs slow" could never be
- called fixed, while "Documentation should cover the topic Embedding"
- or "The page at <http://en.wikipedia.org/wiki/Example> should load
- in less than five seconds" would have a criterion. A good summary of
- the bug will also help others in finding existing bugs and prevent
- filing of duplicates.
-
-- If the bug is a graphical problem, you may want to ask for a
- screenshot to attach to the bug report. Make sure to ask that the
- screenshot should not contain any confidential information.
-
-Is it a duplicate?
-------------------
-
-Some reports in Bugzilla have already been reported before so you can
-[search for an already existing
-report](https://bugzilla.redhat.com/query.cgi?format=advanced). We do
-not recommend to spend too much time on it; if a bug is filed twice,
-someone else will mark it as a duplicate later. If the bug is a
-duplicate, mark it as a duplicate in the resolution box below the
-comment field by setting the **CLOSED DUPLICATE** status, and shortly
-explain your action in a comment for the reporter. When marking a bug as
-a duplicate, it is required to reference the original bug.
-
-If you think that you have found a duplicate but you are not totally
-sure, just add a comment like "This bug looks related to bug XXXXX" (and
-replace XXXXX by the bug number) so somebody else can take a look and
-help judging.
-
-You can also take a look at
-https://bugzilla.redhat.com/page.cgi?id=browse.html&product=GlusterFS&product_version>=&bug\_status=all&tab=duplicates's
-list of existing duplicates
-
-Is it assigned to correct component of GlusterFS?
--------------------------------------------------
-
-Make sure the bug is assigned on right component. Below are the list of
-GlusterFs components in bugzilla.
-
-- access control - Access control translator
-- BDB - Berkeley DB backend storage
-- booster - LD\_PRELOAD'able access client
-- build - Compiler, package management and platform specific warnings
- and errors
-- cli -gluster command line
-- core - Core features of the filesystem
-- distribute - Distribute translator (previously DHT)
-- errorgen - Error Gen Translator
-- fuse -mount/fuse translator and patched fuse library
-- georeplication - Gluster Geo-Replication
-- glusterd - Management daemon
-- HDFS - Hadoop application support over GlusterFS
-- ib-verbs - Infiniband verbs transport
-- io-cache - IO buffer caching translator
-- io-threads - IO threads performance translator
-- libglusterfsclient- API interface to access glusterfs volumes
- programatically
-- locks - POSIX and internal locks
-- logging - Centralized logging, log messages, log rotation etc
-- nfs- NFS component in GlusterFS
-- nufa- Non-Uniform Filesystem Scheduler Translator
-- object-storage - Object Storage
-- porting - Porting GlusterFS to different operating systems and
- platforms
-- posix - POSIX (API) based backend storage
-- protocol -Client and Server protocol translators
-- quick-read- Quick Read Translator
-- quota - Volume & Directory quota translator
-- rdma- RDMA transport
-- read-ahead - Read ahead (file) performance translator
-- replicate- Replication translator (previously AFR)
-- rpc - RPC Layer
-- scripts - Build scripts, mount scripts, etc.
-- stat-prefetch - Stat prefetch translator
-- stripe - Striping (RAID-0) cluster translator
-- trace- Trace translator
-- transport - Socket (IPv4, IPv6, unix, ib-sdp) and generic transport
- code
-- unclassified - Unclassified - to be reclassified as other components
-- unify - Unify translator and schedulers
-- write-behind- Write behind performance translator
-- libgfapi - APIs for GlusterFS
-- tests- GlusterFS Test Framework
-- gluster-hadoop - Hadoop support on GlusterFS
-- gluster-hadoop-install - Automated Gluster volume configuration for
- Hadoop Environments
-- gluster-smb - gluster smb
-- puppet-gluster - A puppet module for GlusterFS
-
-Tips for searching:
-
-- As it is often hard for reporters to find the right place (product
- and component) where to file a report, also search for duplicates
- outside same product and component of the bug report you are
- triaging.
-- Use common words and try several times with different combinations,
- as there could be several ways to describe the same problem. If you
- choose the proper and common words, and you try several times with
- different combinations of those, you ensure to have matching
- results.
-- Drop the ending of a verb (e.g. search for "delet" so you get
- reports for both "delete" and "deleting"), and also try similar
- words (e.g. search both for "delet" and "remov").
-- Search using the date range delimiter: Most of the bug reports are
- recent, so you can try to increase the search speed using date
- delimiters by going to "Search by Change History" on the [search
- page](https://bugzilla.redhat.com/query.cgi?format=advanced).
- Example: search from "2011-01-01" or "-730d" (to cover the last two
- years) to "Now".
-
-Are the fields correct?
------------------------
-
-### Summary
-
-Sometimes the summary does not summarize the bug itself well. You may
-want to update the bug summary to make the report distinguishable. A
-good title may contain:
-
-- A brief explanation of the root cause (if it was found)
-- Some of the symptoms people are experiencing
-
-### Adding people to the "CC" or changing the "Assigned to" field
-
-Normally, developers and potential assignees of an area are already
-CC'ed by default, but sometimes reports describe general issues or are
-filed against common bugzilla products. Only if you know developers who
-work in the area covered by the bug report, and if you know that these
-developers accept getting CCed or assigned to certain reports, you can
-add that person to the CC field or even assign the bug report to
-her/him.
-
-To get an idea who works in which area, check To know component owners ,
-you can check the "MAINTAINERS" file in root of glusterfs code directory
-or querying changes in [Gerrit](http://review.gluster.org) (see
-[Simplified dev workflow](./Simplified Development Workflow.md))
-
-### Severity And Priority
-
-Please see below for information on the available values and their
-meanings.
-
-#### Severity
-
-This field is a pull-down of the external weighting of the bug report's
-importance and can have the following values:
-
- Severity |Definition
- -------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------
- urgent |catastrophic issues which severely impact the mission-critical operations of an organization. This may mean that the operational servers, development systems or customer applications are down or not functioning and no procedural workaround exists.
- high |high-impact issues in which the customer's operation is disrupted, but there is some capacity to produce
- medium |partial non-critical functionality loss, or issues which impair some operations but allow the customer to perform their critical tasks. This may be a minor issue with limited loss or no loss of functionality and limited impact to the customer's functionality
- low |general usage questions, recommendations for product enhancement, or development work
- unspecified |importance not specified
-
-#### Priority
-
-This field is a pull-down of the internal weighting of the bug report's
-importance and can have the following values:
-
- Priority |Definition
- -------------|------------------------
- urgent |extremely important
- high |very important
- medium |average importance
- low |not very important
- unspecified |importance not specified
-
-
-### Bugs present in multiple Versions
-
-During triaging you might come across a particular bug which is present
-across multiple version of GlusterFS. Here are the course of actions:
-
-- We should have separate bugs for each release (We should
- clone bugs if required)
-- Bugs in released versions should be depended on bug for mainline
- (master branch) if the bug is applicable for mainline.
- - This will make sure that the fix would get merged in master
- branch first then the fix can get ported to other stable
- releases.
-
-*Note: When a bug depends on other bugs, that means the bug cannot be
-fixed unless other bugs are fixed (depends on), or this bug stops other
-bugs being fixed (blocks)*
-
-Here are some examples:
-
-- A bug is raised for GlusterFS 3.5 and the same issue is present in
- mainline (master branch) and GlusterFS 3.6
- - Clone the original bug for mainline.
- - Clone another for 3.6.
- - And have the GlusterFS 3.6 bug and GlusterFS 3.5 bug 'depend on'
- the 'mainline' bug
-
-- A bug is already present for mainline, and the same issue is seen in
- GlusterFS 3.5.
- - Clone the original bug for GlusterFS 3.5.
- - And have the cloned bug (for 3.5) 'depend on' the 'mainline'
- bug.
-
-### Keywords
-
-Many predefined searches for Bugzilla include keywords. One example are
-the searches for the triaging. If the bug is 'NEW' and 'Triaged' is no
-set, you (as a triager) can pick it and use this page to triage it. When
-the bug is 'NEW' and 'Triaged' is in the list of keyword, the bug is
-ready to be picked up by a developer.
-
-**Triaged**
-: Once you are done with triage add the **Triaged** keyword to the
- bug, so that others will know the triaged state of the bug. The
- predefined search at the top of this page will then not list the
- Triaged bug anymore. Instead, the bug should have moved to [this
- list](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=Triaged&product=GlusterFS).
-
-**EasyFix**
-: By adding the **EasyFix** keyword, the bug gets added to the [list
- of bugs that should be simple to fix](./Easy Fix Bugs.md).
- Adding this keyword is encouraged for simple and well defined bugs
- or feature enhancements.
-
-**Patch**
-: When a patch for the problem has been attached or included inline,
- add the **Patch** keyword so that it is clear that some preparation
- for the development has been done already. If course, it would have
- been nicer if the patch was sent to Gerrit for review, but not
- everyone is ready to pass the Gerrit hurdle when they report a bug.
-
-You can also add the **Patch** keyword when a bug has been fixed in
- mainline and the patch(es) has been identified. Add a link to the
- Gerrit change(s) so that backporting to a stable release is made
- simpler.
-
-**Documentation**
-: Add the **Documentation** keyword when a bug has been reported for
- the documentation. This helps editors and writers in finding the
- bugs that they can resolve.
-
-**Tracking**
-: This keyword is used for bugs which are used to track other bugs for
- a particular release. For example [3.6 tracker
- bug](https://bugzilla.redhat.com/showdependencytree.cgi?maxdepth=2&hide_resolved=1&id=glusterfs-3.6.0)
-
-**FutureFeature**
-: This keyword is used for bugs which are used to request for a
- feature enhancement ( RFE - Requested Feature Enhancement) for
- future releases of GlusterFS. If you open a bug by requesting a
- feature which you would like to see in next versions of GlusterFS
- please report with this keyword.
-
-Add yourself to the CC list
----------------------------
-
-By adding yourself to the CC list of bug reports that you change, you
-will receive followup emails with all comments and changes by anybody on
-that individual report. This helps learning what further investigations
-others make. You can change the settings in Bugzilla on which actions
-you want to receive mail.
-
-Bugs For Group Triage
----------------------
-
-If you come across a bug/ bugs or If you think any bug should to go
-thorough the bug triage group, please set NEEDINFO for bugs@gluster.org
-on the bug.
-
-Resolving bug reports
----------------------
-
-See the [Bug report life cycle](./Bug report Life Cycle.md) for
-the meaning of the bug status and resolutions.
-
-Example of Triaged Bugs
------------------------
-
-This Bugzilla
-[filter](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=Triaged&keywords_type=anywords&list_id=2739593&product=GlusterFS&query_format=advanced)
-will list NEW, Triaged Bugs
diff --git a/doc/developer-guide/Bug-report-Life-Cycle.md b/doc/developer-guide/Bug-report-Life-Cycle.md
deleted file mode 100644
index 3749bd6..0000000
--- a/doc/developer-guide/Bug-report-Life-Cycle.md
+++ /dev/null
@@ -1,57 +0,0 @@
-This page describes the life of a bug report.
-
-- When a bug is first reported, it is given the **NEW** status.
-- Once a developer has started, or is planning to work on a bug, the
- status **ASSIGNED** is set. The "Assigned to" field should mention a
- specific developer.
-- If an initial
- [patch](https://en.wikipedia.org/wiki/Patch_(computing)) for a bug
- has been put into the [Gerrit code review
- tool](http://review.gluster.org), the status **POST** should be set
- manually. The status **POST** should only be used when all patches
- for a specific bug have been posted for review.
-- After a review of the patch, and passing any automated regression
- tests, the patch will get merged by one of the maintainers. When the
- patch has been merged into the git repository, a comment is added to
- the bug. Only when all needed patches have been merged, the assigned
- engineer will need to change the status to **MODIFIED**.
-- Once a package is available with fix for the bug, the status should
- be moved to **ON\_QA**.
- - The **Fixed in version** field should get the name/release of
- the package that contains the fix. Packages for multiple
- distributions will mostly get available within a few days after
- the *make dist* tarball was created.
- - This tells the bug reporter that a package is available with fix
- for the bug and that they should test the package.
- - The release maintainer need to do this change to bug status,
- scripts are available (ask *ndevos*).
-- The status **VERIFIED** is set if a QA tester or the reporter
- confirmed the fix after fix is merged and new build with the fix
- resolves the issue.
-- In case the version does not fix the reported bug, the status should
- be moved back to **ASSIGNED** with a clear note on what exactly
- failed.
-- When a report has been solved it is given **CLOSED** status. This
- can mean:
- - **CLOSED/CURRENTRELEASE** when a code change that fixes the
- reported problem has been merged in
- [Gerrit](http://review.gluster.org).
- - **CLOSED/WONTFIX** when the reported problem or suggestion is
- valid, but any fix of the reported problem or implementation of
- the suggestion would be barred from approval by the project's
- Developers/Maintainers (or product managers, if existing).
- - **CLOSED/WORKSFORME** when the problem can not be reproduced,
- when missing information has not been provided, or when an
- acceptable workaround exists to achieve a similar outcome as
- requested.
- - **CLOSED/CANTFIX** when the problem is not a bug, or when it is
- a change that is outside the power of GlusterFS development. For
- example, bugs proposing changes to third-party software can not
- be fixed in the GlusterFS project itself.
- - **CLOSED/DUPLICATE** when the problem has been reported before,
- no matter if the previous report has been already resolved or
- not.
-
-If a bug report was marked as *CLOSED* or *VERIFIED* and it turns out
-that this was incorrect, the bug can be changed to the status *ASSIGNED*
-or *NEW*. \ No newline at end of file
diff --git a/doc/developer-guide/Bug-reporting-template.md b/doc/developer-guide/Bug-reporting-template.md
deleted file mode 100644
index f8d1157..0000000
--- a/doc/developer-guide/Bug-reporting-template.md
+++ /dev/null
@@ -1,55 +0,0 @@
-Template for bug description
-----------------------------
-This template should be in-line to the [Bug reporting guidelines](./Bug Reporting Guidelines.md).
-The template is replacement for the default description template present in [Bugzilla](https://bugzilla.redhat.com)
-
- work in progress
-
-------------------------------------------------------------------------
-
-Description of problem:
-
-Version of GlusterFS package installed:
-
-Location from which the packages are used:
-
-GlusterFS Cluster Information:
-
-- Number of volumes
-- Volume Names
-- Volume on which the particular issue is seen [ if applicable ]
-- Type of volumes
-- Volume options if available
-- Output of `gluster volume info`
-- Output of `gluster volume status`
-- Get the statedump of the volume with the problem
-
-` $ gluster volume statedump `<vol-name>
-
-- Client Information
- - OS Type:
- - Mount type:
- - OS Version:
-
-How reproducible:
-
-Steps to Reproduce:
-
-- 1.
-- 2.
-- 3.
-
-Actual results:
-
-Expected results:
-
-Logs Information:
-
-- Provide possible issues, warnings, errors as a comment to the bug
- - Look for issues/warnings/errors in self-heal logs, rebalance logs, glusterd logs, brick logs, mount logs/nfs logs/smb logs
- - Add the entire logs as attachment, if it is very large to paste as a comment
-
-Additional info:
-
- [Bug\_reporting\_guidelines]: Bug_reporting_guidelines "wikilink"
- [Bugzilla]: https://bugzilla.redhat.com
diff --git a/doc/developer-guide/Building GlusterFS.md b/doc/developer-guide/Building GlusterFS.md
deleted file mode 100644
index ab28782..0000000
--- a/doc/developer-guide/Building GlusterFS.md
+++ /dev/null
@@ -1,147 +0,0 @@
-This page describes how to build and install GlusterFS.
-
-Build Requirements
-------------------
-
-The following packages are required for building GlusterFS,
-
-- GNU Autotools
- - Automake
- - Autoconf
- - Libtool
-- lex (generally flex)
-- GNU Bison
-- OpenSSL
-- libxml2
-- Python 2.x
-- libaio
-- libibverbs
-- librdmacm
-- readline
-- lvm2
-- glib2
-- liburcu
-- cmocka
-- libacl
-- sqlite
-
-### Fedora
-
-The following yum command installs all the build requirements for
-Fedora,
-
- # yum install automake autoconf libtool flex bison openssl-devel libxml2-devel python-devel libaio-devel libibverbs-devel librdmacm-devel readline-devel lvm2-devel glib2-devel userspace-rcu-devel libcmocka-devel libacl-devel sqlite-devel
-
-### Ubuntu
-
-The following apt-get command will install all the build requirements on
-Ubuntu,
-
- $ sudo apt-get install make automake autoconf libtool flex bison pkg-config libssl-dev libxml2-dev python-dev libaio-dev libibverbs-dev librdmacm-dev libreadline-dev liblvm2-dev libglib2.0-dev liburcu-dev libcmocka-dev libsqlite3-dev libacl1-dev
-
-Building from Source
---------------------
-
-This section describes how to build GlusterFS from source. It is assumed
-you have a copy of the GlusterFS source (either from a released tarball
-or a git clone). All the commands below are to be run with the source
-directory as the working directory.
-
-### Configuring for building
-
-Run the below commands once for configuring and setting up the build
-process.
-
-Run autogen to generate the configure script.
-
- $ ./autogen.sh
-
-Once autogen completes successfully a configure script is generated. Run
-the configure script to generate the makefiles.
-
- $ ./configure
-
-If the above build requirements have been installed, running the
-configure script should give the below configure summary,
-
- GlusterFS configure summary
- ===========================
- FUSE client          : yes
- Infiniband verbs     : yes
- epoll IO multiplex   : yes
- argp-standalone      : no
- fusermount           : yes
- readline             : yes
- georeplication       : yes
- Linux-AIO            : yes
- Enable Debug         : no
- Block Device xlator  : yes
- glupy                : yes
- Use syslog           : yes
- XML output           : yes
- QEMU Block formats   : yes
- Encryption xlator    : yes
-
-During development it is good to enable a debug build. To do this run
-configure with a '--enable-debug' flag.
-
- $ ./configure --enable-debug
-
-Further configuration flags can be found by running configure with a
-'--help' flag,
-
- $ ./configure --help
-
-### Building
-
-Once configured, GlusterFS can be built with a simple make command.
-
- $ make
-
-To speed up the build process on a multicore machine, add a '-jN' flag,
-where N is the number of parallel jobs.
-
-### Installing
-
-Run 'make install' to install GlusterFS. By default, GlusterFS will be
-installed into '/usr/local' prefix. To change the install prefix, give
-the appropriate option to configure. If installing into the default
-prefix, you might need to use 'sudo' or 'su -c' to install.
-
- $ sudo make install
-
-### Running GlusterFS
-
-GlusterFS can be only run as root, so the following commands will need
-to be run as root. If you've installed into the default '/usr/local'
-prefix, add '/usr/local/sbin' and '/usr/local/bin' to your PATH before
-running the below commands.
-
-A source install will generally not install any init scripts. So you
-will need to start glusterd manually. To manually start glusterd just
-run,
-
- # glusterd
-
-This will start glusterd and fork it into the background as a daemon
-process. You now run 'gluster' commands and make use of GlusterFS.
-
-Building packages
------------------
-
-### Building RPMs
-
-Building RPMs is really simple. On a RPM based system, for eg. Fedora,
-get the source and do the configuration steps as shown in the 'Building
-from Source' section. After the configuration step, run the following
-steps to build RPMs,
-
- $ cd extras/LinuxRPM
- $ make glusterrpms
-
-This will create rpms from the source in 'extras/LinuxRPM'. *(Note: You
-will need to install the rpmbuild requirements including rpmbuild and
-mock)*
-
-A more detailed description for building RPMs can be found at
-[CompilingRPMS](./Compiling RPMS.md).
diff --git a/doc/developer-guide/Compiling-RPMS.md b/doc/developer-guide/Compiling-RPMS.md
deleted file mode 100644
index 7a243de..0000000
--- a/doc/developer-guide/Compiling-RPMS.md
+++ /dev/null
@@ -1,178 +0,0 @@
-How to compile GlusterFS RPMs from git source, for RHEL/CentOS, and Fedora
---------------------------------------------------------------------------
-
-Creating rpm's of GlusterFS from git source is fairly easy, once you
-know the steps.
-
-RPMS can be compiled on at least the following OS's:
-
-- Red Hat Enterprise Linux 5, 6 (& 7 when available)
-- CentOS 5, 6 (& 7 when available)
-- Fedora 16-20
-
-Specific instructions for compiling are below. If you're using:
-
-- Fedora 16-20 - Follow the Fedora steps, then do all of the Common
- steps.
-- CentOS 5.x - Follow the CentOS 5.x steps, then do all of the Common
- steps
-- CentOS 6.x - Follow the CentOS 6.x steps, then do all of the Common
- steps.
-- RHEL 6.x - Follow the RHEL 6.x steps, then do all of the Common
- steps.
-
-Note - these instructions have been explicitly tested on all of CentOS
-5.10, RHEL 6.4, CentOS 6.4+, and Fedora 16-20. Other releases of
-RHEL/CentOS and Fedora may work too, but haven't been tested. Please
-update this page appropriately if you do so. :)
-
-### Preparation steps for Fedora 16-20 (only)
-
-​1. Install gcc, the python development headers, and python setuptools:
-
- $ sudo yum -y install gcc python-devel python-setuptools
-
-​2. If you're compiling GlusterFS version 3.4, then install
-python-swiftclient. Other GlusterFS versions don't need it:
-
- $ sudo easy_install simplejson python-swiftclient
-
-Now follow through the **Common Steps** part below.
-
-### Preparation steps for CentOS 5.x (only)
-
-You'll need EPEL installed first and some CentOS specific packages. The
-commands below will get that done for you. After that, follow through
-the "Common steps" section.
-
-​1. Install EPEL first:
-
- $ curl -OL http://download.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
- $ sudo yum -y install epel-release-5-4.noarch.rpm --nogpgcheck
-
-​2. Install the packages required only on CentOS 5.x:
-
- $ sudo yum -y install buildsys-macros gcc ncurses-devel python-ctypes python-sphinx10 \
-   redhat-rpm-config
-
-Now follow through the **Common Steps** part below.
-
-### Preparation steps for CentOS 6.x (only)
-
-You'll need EPEL installed first and some CentOS specific packages. The
-commands below will get that done for you. After that, follow through
-the "Common steps" section.
-
-​1. Install EPEL first:
-
- $ sudo yum -y install http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
-
-​2. Install the packages required only on CentOS:
-
- $ sudo yum -y install python-webob1.0 python-paste-deploy1.5 python-sphinx10 redhat-rpm-config
-
-Now follow through the **Common Steps** part below.
-
-### Preparation steps for RHEL 6.x (only)
-
-You'll need EPEL installed first and some RHEL specific packages. The 2
-commands below will get that done for you. After that, follow through
-the "Common steps" section.
-
-​1. Install EPEL first:
-
- $ sudo yum -y install http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
-
-​2. Install the packages required only on RHEL:
-
- $ sudo yum -y --enablerepo=rhel-6-server-optional-rpms install python-webob1.0 \
-   python-paste-deploy1.5 python-sphinx10 redhat-rpm-config
-
-Now follow through the **Common Steps** part below.
-
-### Common Steps
-
-These steps are for both Fedora and RHEL/CentOS. At the end you'll have
-the complete set of GlusterFS RPMs for your platform, ready to be
-installed.
-
-**NOTES for step 1 below:**
-
-- If you're on RHEL/CentOS 5.x and get a message about lvm2-devel not
- being available, it's ok. You can ignore it. :)
-- If you're on RHEL/CentOS 6.x and get any messages about
- python-eventlet, python-netifaces, python-sphinx and/or pyxattr not
- being available, it's ok. You can ignore them. :)
-
-​1. Install the needed packages
-
- $ sudo yum -y --disablerepo=rhs* --enablerepo=*optional-rpms install git autoconf \
-   automake bison cmockery2-devel dos2unix flex fuse-devel glib2-devel libaio-devel \
-   libattr-devel libibverbs-devel librdmacm-devel libtool libxml2-devel lvm2-devel make \
-   openssl-devel pkgconfig pyliblzma python-devel python-eventlet python-netifaces \
-   python-paste-deploy python-simplejson python-sphinx python-webob pyxattr readline-devel \
-   rpm-build tar libcmocka-devel
-
-​2. Clone the GlusterFS git repository
-
- $ git clone git://git.gluster.org/glusterfs
- $ cd glusterfs
-
-​3. Choose which branch to compile
-
-If you want to compile the latest development code, you can skip this
-step and go on to the next one.
-
-If instead you want to compile the code for a specific release of
-GlusterFS (such as v3.4), get the list of release names here:
-
- $ git branch -a | grep release
-   remotes/origin/release-2.0
-   remotes/origin/release-3.0
-   remotes/origin/release-3.1
-   remotes/origin/release-3.2
-   remotes/origin/release-3.3
-   remotes/origin/release-3.4
-   remotes/origin/release-3.5
-
-Then switch to the correct release using the git "checkout" command, and
-the name of the release after the "remotes/origin/" bit from the list
-above:
-
- $ git checkout release-3.4
-
-**NOTE -** The CentOS 5.x instructions have only been tested for the
-master branch in GlusterFS git. It is unknown (yet) if they work for
-branches older then release-3.5.
-
-​4. Configure and compile GlusterFS
-
-Now you're ready to compile Gluster:
-
- $ ./autogen.sh
- $ ./configure --enable-fusermount
- $ make dist
-
-​5. Create the GlusterFS RPMs
-
- $ cd extras/LinuxRPM
- $ make glusterrpms
-
-That should complete with no errors, leaving you with a directory
-containing the RPMs.
-
- $ ls -l *rpm
- -rw-rw-r-- 1 jc jc 3966111 Mar  2 12:15 glusterfs-3git-1.el5.centos.src.rpm
- -rw-rw-r-- 1 jc jc 1548890 Mar  2 12:17 glusterfs-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc   66680 Mar  2 12:17 glusterfs-api-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc   20399 Mar  2 12:17 glusterfs-api-devel-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  123806 Mar  2 12:17 glusterfs-cli-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc 7850357 Mar  2 12:17 glusterfs-debuginfo-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  112677 Mar  2 12:17 glusterfs-devel-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  100410 Mar  2 12:17 glusterfs-fuse-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  187221 Mar  2 12:17 glusterfs-geo-replication-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  299171 Mar  2 12:17 glusterfs-libs-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc   44943 Mar  2 12:17 glusterfs-rdma-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  123065 Mar  2 12:17 glusterfs-regression-tests-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc   16224 Mar  2 12:17 glusterfs-resource-agents-3git-1.el5.centos.x86_64.rpm
- -rw-rw-r-- 1 jc jc  654043 Mar  2 12:17 glusterfs-server-3git-1.el5.centos.x86_64.rpm
diff --git a/doc/developer-guide/Developers-Index.md b/doc/developer-guide/Developers-Index.md
index a523a46..9bcbcdc 100644
--- a/doc/developer-guide/Developers-Index.md
+++ b/doc/developer-guide/Developers-Index.md
@@ -12,44 +12,17 @@ involved. We don't require a signed contributor license agreement or
copyright assignment, but we do require a "signed-off-by" line on each
code check-in.
-- [Simplified Developer Workflow](./Simplified Development Workflow.md)
- - A simpler and faster intro to developing with GlusterFS, than the
- doc below.
-- [Developer Workflow](./Development Workflow.md) - this tells
- you about our patch requirements, tools we use, and more. Required
- reading if you want to contribute code.
- [License
Change](http://www.gluster.org/2012/05/glusterfs-license-change/) -
we recently changed the client library code to a dual license under
the GPL v2 and the LGPL v3 or later
- [GlusterFS Coding Standards](./coding-standard.md)
-Compiling Gluster
------------------
-
-- [Compiling RPMS](./Compiling RPMS.md) - Step by step
- instructions for compiling Gluster RPMS
-- [Building GlusterFS](./Building GlusterFS.md) - How to compile
- Gluster from source code. Including instructions for Ubuntu.
-
Developing
----------
-- [Projects](./Projects.md) - Ideas for projects you could
- create
- [Language Bindings](./Language Bindings.md) - Connect to
GlusterFS using various language bindings
-- [EasyFix\_Bugs](./Easy Fix Bugs.md) - Easy to fix bugs of
- GlusterFS. One of the best place to start contributing to GlusterFS.
-- [Fixing issues reported by tools for static code
- analysis](./Fixing issues reported by tools for static code analysis.md)
- - This is a good starting point for developers to fix bugs in
- GlusterFS project.
-- [Backport Wishlist](./Backport Wishlist.md) - Problems fixed
- in the master branch might need to get fixed in stable release
- branches too.
- The [Backport Guidelines](./Backport Guidelines.md) describe the steps that
- branches too.
Adding File operations
----------------------
@@ -93,35 +66,8 @@ Testing/Debugging
- [Using the Gluster Test
Framework](./Using Gluster Test Framework.md) - Step by
step instructions for running the Gluster Test Framework
-- [Our Jenkins Infrastructure](./Jenkins Infrastructure.md) - A
- braindump of the Jenkins infrastructure we have in place for
- automated testing
-- [Manual steps for setting up a Jenkins slave VM in
- Rackspace](./Jenkins Manual Setup.md) - Steps for setting up a slave
- VM in Rackspace
- [Coredump Analysis](./coredump-analysis.md) - Steps to analize coredumps generated by regression machines.
-Bug Handling
-------------
-
-- [Bug reporting guidelines](./Bug Reporting Guidelines.md) -
- Guideline for reporting a bug in GlusterFS
-- [Bug triage guidelines](./Bug Triage.md) - Guideline on how to
- triage bugs for GlusterFS
-- [Bug report life cycle in
- Bugzilla](./Bug report Life Cycle.md) - Information about bug
- life cycle
-
-Patch Acceptance
-----------------
-
-- The [Guidelines For
- Maintainers](./Guidelines For Maintainers.md) explains when
- maintainers can merge patches.
-
Release Process
---------------
-
- [Versioning](./versioning.md)
-- [GlusterFS Release Process](./GlusterFS Release process.md) -
- Our release process / checklist
diff --git a/doc/developer-guide/Development-Workflow.md b/doc/developer-guide/Development-Workflow.md
deleted file mode 100644
index 4c80327..0000000
--- a/doc/developer-guide/Development-Workflow.md
+++ /dev/null
@@ -1,457 +0,0 @@
-Development work flow of Gluster
-================================
-
-This document provides a detailed overview of the development model
-followed by the GlusterFS project.
-
-For a simpler overview visit
-[Simplified develoment workflow](./Simplified Development Workflow.md).
-
-Basics
-------
-
-The GlusterFS development model largely revolves around the features and
-functionality provided by Git version control system, Gerrit code review
-system and Jenkins continuous integration system. It is a primer for a
-contributor to the project.
-
-### Git
-
-Git is a extremely flexible, distributed version control system.
-GlusterFS' main git repository is at <http://git.gluster.org> and public
-mirrors are at GlusterForge
-(https://forge.gluster.org/glusterfs-core/glusterfs) and at GitHub
-(https://github.com/gluster/glusterfs). The development repo is hosted
-inside Gerrit and every code merge is instantly replicated to the public
-mirrors.
-
-A good introduction to Git can be found at
-<http://www-cs-students.stanford.edu/~blynn/gitmagic/>.
-
-### Gerrit
-
-Gerrit is an excellent code review system which is developed with a git
-based workflow in mind. The GlusterFS project code review system is
-hosted at [review.gluster.org](http://review.gluster.org). Gerrit works
-on "Change"s. A change is a set of modifications to various files in
-your repository to accomplish a task. It is essentially one large git
-commit with all the necessary changes which can be both built and
-tested.
-
-Gerrit usage is described later in 'Review Process' section.
-
-### Jenkins
-
-Jenkins is a Continuous Integration build system. Jenkins is hosted at
-<http://build.gluster.org>. Jenkins is configured to work with Gerrit by
-setting up hooks. Every "Change" which is pushed to Gerrit is
-automatically picked up by Jenkins, built and smoke tested. Output of
-all builds and tests can be viewed at
-<http://build.gluster.org/job/smoke/>. Jenkins is also setup with a
-'regression' job which is designed to execute test scripts provided as
-part of the code change.
-
-Preparatory Setup
------------------
-
-Here is a list of initial one-time steps before you can start hacking on
-code.
-
-### Register
-
-Sign up for an account at <http://review.gluster.org> by clicking
-'Register' on the right-hand top. You can use your gmail login as the
-openID identity.
-
-### Preferred email
-
-On first login, add your git/work email to your identity. You will have
-to click on the URL which is sent to your email and set up a proper Full
-Name. Make sure you set your git/work email as your preferred email.
-This should be the email address from which all your code commits are
-associated.
-
-### Set Username
-
-Select yourself a username.
-
-### Watch glusterfs
-
-In Gerrit settings, watch the 'glusterfs' project. Tick on all the three
-(New Changes, All Comments, Submitted Changes) types of notifications.
-
-### Email filters
-
-Set up a filter rule in your mail client to tag or classify mails with
-the header
-
- List-Id: <gerrit-glusterfs.review.gluster.org>
-
-as mails originating from the review system.
-
-### SSH keys
-
-Provide your SSH public key into Gerrit so that you can successfully
-access the development git repo as well as push changes for
-review/merge.
-
-### Clone a working tree
-
-Get yourself a working tree by cloning the development repository from
-Gerrit
-
- sh$ git clone ssh://[username)@]git.gluster.org/glusterfs.git glusterfs
-
-Branching policy
-----------------
-
-This section describes both, the branching policies on the public repo
-as well as the suggested best-practice for local branching
-
-### Master/release branches
-
-In glusterfs.git, the master branch is the forward development branch.
-This is where new features come in first. In fact this is where almost
-every change (commit) comes in first. The master branch is always kept
-in a buildable state and smoke tests pass.
-
-Release trains (3.1.z, 3.2.z, 3.2.z) each have a branch originating from
-master. Code freeze of each new release train is marked by the creation
-of the release-3.y branch. At this point no new features are added to
-the release-3.y branch. All fixes and commits first get into master.
-From there, only bug fixes get backported to the relevant release
-branches. From the release-3.y branch, actual release code snapshots
-(e.g. glusterfs-3.2.2 etc.) are tagged (git annotated tag with 'git tag
--a') shipped as a tarball.
-
-### Personal per-task branches
-
-As a best practice, it is recommended you perform all code changes for a
-task in a local branch in your working tree. The local branch should be
-created from the upstream branch to which you intend to submit the
-change. If you are submitting changes to master branch, first create a
-local task branch like this -
-
- sh$ git checkout master
- sh$ git branch bug-XYZ && git checkout bug-XYZ
- ... <hack, commit>
-
-If you are backporting a fix to a release branch, or making a new change
-to a release branch, your commands would be slightly different. If you
-are checking out a release branch in your local working tree for the
-first time, make sure to set it up as a remote tracking branch like this
--
-
- sh$ git checkout -b release-3.2 origin/release-3.2
-
-The above step is not necessary to be repeated. In the future if you
-want to work to the release branch -
-
- sh$ git checkout release-3.2
- sh$ git branch bug-XYZ-release-3.2 && git checkout bug-XYZ-release-3.2
- ... <cherry-pick, hack, commit>
-
-Building
---------
-
-### Environment Setup
-
-**For details about the required packages for the build environment
-refer : [Building GlusterFS](./Building GlusterFS.md)**
-
-Ubuntu:
-
-To setup the build environment on an Ubuntu system, type the following
-command to install the required packages:
-
- sudo apt-get -y install python-pyxattr libreadline-dev tar
- python-pastedeploy python-simplejson python-sphinx python-webob libssl-dev
- pkg-config python-dev python-eventlet python-netifaces libaio-dev libibverbs-dev
- libtool libxml2-dev liblvm2-dev make autoconf automake bison dos2unix flex libfuse-dev
-
-CentOS/RHEL/Fedora:
-
-On Fedora systems, install the required packages by following the
-instructions in [CompilingRPMS](./Compiling RPMS.md).
-
-### Creating build environment
-
-Once the required packages are installed for your appropiate system,
-generate the build configuration:
-
- sh$ ./autogen.sh
- sh$ ./configure --enable-fusermount
-
-### Build and install
-
-#### GlusterFS
-
-Ubuntu:
-
-Type the following to build and install GlusterFS on the system:
-
- sh$ make
- sh$ make install
-
-CentOS/RHEL/Fedora:
-
-In an rpm based system, there are two methods to build GlusterFS. One is
-to use the method describe above for *Ubuntu*. The other is to build and
-install RPMS as described in [CompilingRPMS](./Compiling RPMS.md).
-
-#### GlusterFS UFO/SWIFT
-
-To build and run Gluster UFO you can do the following:
-
-1. Build, create, and install the RPMS as described in
- [CompilingRPMS](./Compiling RPMS.md).
-2. Configure UFO/SWIFT as described in [Howto Using UFO SWIFT - A quick
- and dirty setup
- guide](http://www.gluster.org/2012/09/howto-using-ufo-swift-a-quick-and-dirty-setup-guide)
-
-Commit policy
--------------
-
-For a Gerrit based work flow, each commit should be an independent,
-buildable and testable change. Typically you would have a local branch
-per task, and most of the times that branch will have one commit.
-
-If you have a second task at hand which depends on the changes of the
-first one, then technically you can have it as a separate commit on top
-of the first commit. But it is important that the first commit should be
-a testable change by itself (if not, it is an indication that the two
-commits are essentially part of a single change). Gerrit accommodates
-these situations by marking Change 1 as a "dependency" of Change 2
-(there is a 'Dependencies' tab in the Change page in Gerrit)
-automatically when you push the changes for review from the same local
-branch.
-
-You will need to sign-off your commit (git commit -s) before sending the
-patch for review. By signing off your patch, you agree to the terms
-listed under "Developer's Certificate of Origin" section in the
-CONTRIBUTING file available in the repository root.
-
-Provide a meaningful commit message. Your commit message should be in
-the following format
-
-- A short one line subject describing what the patch accomplishes
-- An empty line following the subject
-- Situation necessitating the patch
-- Description of the code changes
-- Reason for doing it this way (compared to others)
-- Description of test cases
-
-### Test cases
-
-Part of the workflow is to aggregate and execute pre-commit test cases
-which accompany patches, cumulatively for every new patch. This
-guarantees that tests which are working till the present are not broken
-with the new patch. Every change submitted to Gerrit much include test
-cases in
-
- tests/group/script.t
-
-as part of the patch. This is so that code changes and accompanying test
-cases are reviewed together. All new commits now come under the
-following categories w.r.t test cases:
-
-#### New 'group' directory and/or 'script.t'
-
-This is typically when code is adding a new module and/or feature
-
-#### Extend/Modify old test cases in existing scripts
-
-This is typically when present behavior (default values etc.) of code is
-changed
-
-#### No test cases
-
-This is typically when code change is trivial (e.g. fixing typos in
-output strings, code comments)
-
-#### Only test case and no code change
-
-This is typically when we are adding test cases to old code (already
-existing before this regression test policy was enforced)
-
-More details on how to work with test case scripts can be found in
-
-tests/README
-
-Review process
---------------
-
-### rfc.sh
-
-After doing the local commit, it is time to submit the code for review.
-There is a script available inside glusterfs.git called rfc.sh. You can
-submit your changes for review by simply executing
-
- sh$ ./rfc.sh
-
-This script does the following:
-
-- The first time it is executed, it downloads a git hook from
- <http://review.gluster.org/tools/hooks/commit-msg> and sets it up
- locally to generate a Change-Id: tag in your commit message (if it
- was not already generated.)
-- Rebase your commit against the latest upstream HEAD. This rebase
- also causes your commits to undergo massaging from the just
- downloaded commit-msg hook.
-- Prompt for a Bug Id for each commit (if it was not already provded)
- and include it as a "BUG:" tag in the commit log. You can just hit
- <enter> at this prompt if your submission is purely for review
- purposes.
-- Push the changes to review.gluster.org for review. If you had
- provided a bug id, it assigns the topic of the change as "bug-XYZ".
- If not it sets the topic as "rfc".
-
-On a successful push, you will see a URL pointing to the change in
-review.gluster.org
-
-Auto verification
------------------
-
-The integration between Jenkins and Gerrit triggers an event in Jenkins
-on every push of changes, to pick up the change and run build and smoke
-test on it.
-
-If the build and smoke tests execute successfuly, Jenkins marks the
-change as '+0 Verified'. If they fail, '-1 Verified' is marked on the
-change. This means passing the automated smoke test is a necessary
-condition but not sufficient.
-
-It is important to note that Jenkins verification is only a generic
-verification of high level tests. More concentrated testing effort for
-the patch is necessary with manual verification.
-
-If auto verification fails, it is a good reason to skip code review till
-a fixed change is pushed later. You can click on the build URL
-automatically put as a comment to inspect the reason for auto
-verification failure. In the Jenkins job page, you can click on the
-'Console Output' link to see the exact point of failure.
-
-Reviewing / Commenting
-----------------------
-
-Code review with Gerrit is relatively easy compared to other available
-tools. Each change is presented as multiple files and each file can be
-reviewed in Side-by-Side mode. While reviewing it is possible to comment
-on each line by double-clicking on it and writing in your comments in
-the text box. Such in-line comments are saved as drafts, till you
-finally publish them as a Review from the 'Change page'.
-
-There are many small and handy features in Gerrit, like 'starring'
-changes you are interested to follow, setting the amount of context to
-view in the side-by-side view page etc.
-
-Incorporate, Amend, rfc.sh, Reverify
-------------------------------------
-
-Code review comments are notified via email. After incorporating the
-changes in code, you can mark each of the inline comment as 'done'
-(optional). After all the changes to your local files, amend the
-previous commit with these changes with -
-
- sh$ git commit -a --amend
-
-Push the amended commit by executing rfc.sh. If your previous push was
-an "rfc" push (i.e, without a Bug Id) you will be prompted for a Bug Id
-again. You can re-push an rfc change without any other code change too
-by giving a Bug Id.
-
-On the new push, Jenkins will re-verify the new change (independent of
-what the verification result was for the previous push).
-
-It is the Change-Id line in the commit log (which does not change) that
-associates the new push as an update for the old push (even though they
-had different commit ids) under the same Change. In the side-by-side
-view page, it is possible to set knobs in the 'Patch History' tab to
-view changes between patches as well. This is handy to inspect how
-review comments were incorporated.
-
-If further changes are found necessary, comments can be made on the new
-patch as well, and the same cycle repeats.
-
-If no further changes are necessary, the reviewer can mark the patch as
-reviewed with a certain score depending on the depth of review and
-confidence (+1 or +2). A -1 review indicates non-agreement for the
-change to get merged upstream.
-
-Regression tests and test cases
--------------------------------
-
-All code changes which are not trivial (typo fixes, code comment
-changes) must be accompanied with either a new test case script or
-extend/modify an existing test case script. It is important to review
-the test case in conjunction with the code change to analyse whether the
-code change is actually verified by the test case.
-
-Regression tests (i.e, execution of all test cases accumulated with
-every commit) is not automatically triggered as the test cases can be
-extensive and is quite expensive to execute for every change submission
-in the review/resubmit cycle. Instead it is triggered by the
-maintainers, after code review. Passing the regression test is a
-necessary condition for merge along with code review points.
-
-Submission Qualifiers
----------------------
-
-For a change to get merged, there are two qualifiers which are enforced
-by the Gerrit system. They are - A change should have at least one '+2
-Reviewed', and a change should have at least one '+1 Verified'
-(regression test). The project maintainer will merge the changes once a
-patch meets these qualifiers.
-
-Submission Disqualifiers
-------------------------
-
-There are three types of "negative votes".
-
--1 Verified
-
--1 Code-Review ("I would prefer that you didn't submit this")
-
--2 Code-Review ("Do not submit")
-
-The implication and scope of each of the three are different. They
-behave differently as changes are resubmitted as new patchsets.
-
-### -1 Verified
-
-Anybody voting -1 Verified will prevent \*that patchset only\* from
-getting merged. The flag is automatically cleared on the next patchset
-post. The intention is that this vote is based on the result of some
-kind of testing. A voter is expected to explain the test case which
-failed. Jenkins jobs (smoke, regression, ufounit) use this field for
-voting -1/0/+1. When voting -1, Jenkins posts the link to the URL which
-has the console output of the failed job.
-
-### -1 Code-Review ("I would prefer that you didn't submit this")
-
-This is an advisory vote based on the content of the patch. Typically
-issues in source code (both design and implementation), source code
-comments, log messages, license headers etc. found by human inspection.
-The reviewer explains the specific issues by commenting against the most
-relevant lines of source code in the patch. On a resubmission, -1 votes
-are cleared automatically. It is the responsibility of the maintainers
-to honor -1 Code-Review votes from reviewers (by not merging the
-patches), and inspecting that -1 comments on previous submissions are
-addressed in the new patchset. Generally this is the recommended
-"negative" vote.
-
-### -2 Code-Review ("Do not submit")
-
-This is a stronger vote which actually prevents Gerrit from merging the
-patch. The -2 vote persists even after resubmission and continues to
-prevent the patch from getting merged, until the voter revokes the -2
-vote (and then is further subjected to Submission Qualifiers). Typically
-one would vote -2 if they are \*against the goal\* of what the patch is
-trying to achieve (and not an issue with the patch, which can change on
-resubmission). A reviewer would also vote -2 on a patch even if there is
-agreement with the goal, but the issue in the code is of such a critical
-nature that the reviewer personally wants to inspect the next patchset
-and only then revoke the vote after finding the new patch satisfactory.
-This prevents the merge of the patch in the mean time. Every registered
-user has the right to exercise the -2 Code review vote, and cannot be
-overridden by the maintainers.
diff --git a/doc/developer-guide/Easy-Fix-Bugs.md b/doc/developer-guide/Easy-Fix-Bugs.md
deleted file mode 100644
index 9ba3621..0000000
--- a/doc/developer-guide/Easy-Fix-Bugs.md
+++ /dev/null
@@ -1,35 +0,0 @@
-Fixing easy bugs is an excellent method to start contributing patches to
-Gluster.
-
-- Bugs which are marked with EasyFix flag can be found from below
- BugZilla query.
- - [Bugzilla Query For EasyFix
- Bugs](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=EasyFix&list_id=2626252&product=GlusterFS)
- - [RSS-feed for EasyFix Gluster Bugs](http://goo.gl/OpQwlv)
-- To fix EasyFix bugs,
- - When you pick an EasyFix you want to work on, assign it to
- yourself and move it to ASSIGNED
- - Check
- [Bug report life cycle](./Bug report Life Cycle.md) and
- follow it.
- - Check Developers page for details about development workflow,
- GlusterFS design documents etc.
-
-Sometimes an *Easy Fix* bug has a patch attached. In those cases,
-the *Patch* keyword has been added to the bug. These bugs can be
-used by new contributors that would like to verify their workflow. [Bug
-1099645](https://bugzilla.redhat.com/1099645) is one example of those.
-
-### Guidelines for new comers
-
-- While trying to write a patch, do not hesitate to ask questions.
-- If something in the documentation is unclear, we do need to know so
- that we can improve it.
-- There are no stupid questions, and it's more stupid to not ask
- questions that others can easily answer. Always assume that if you
- have a question, someone else would like to hear the answer too.
-
-[Reach out](http://gluster.org/community/index.html) to the developers
-in \#gluster or \#gluster-dev on Freenode IRC, or on one of the mailing
-lists, try to keep the discussions public so that anyone can learn from
-it.
diff --git a/doc/developer-guide/Fixing-issues-reported-by-tools-for-static-code-analysis.md b/doc/developer-guide/Fixing-issues-reported-by-tools-for-static-code-analysis.md
deleted file mode 100644
index 5a3dceb..0000000
--- a/doc/developer-guide/Fixing-issues-reported-by-tools-for-static-code-analysis.md
+++ /dev/null
@@ -1,66 +0,0 @@
-Static Code Analysis Tools
---------------------------
-
-Bug fixes for issues reported by *Static Code Analysis Tools* should
-follow [Development Work Flow](./Development Workflow.md)
-
-### Coverity
-
-GlusterFS is part of [Coverity's](https://scan.coverity.com/) scan
-program.
-
-- To see Coverity issues you have to be a member of the GlusterFS
- project in Coverity scan website.
-- Here is the link to [Coverity scan
- website](https://scan.coverity.com/projects/987)
-- Go to above link and subscribe to GlusterFS project (as
- contributor). It will send a request to Admin for including you in
- the Project.
-- Once admins for the GlusterFS Coverity scan approve your request,
- you will be able to see the defects raised by Coverity.
-- [BZ 789278](https://bugzilla.redhat.com/show_bug.cgi?id=789278)
- should be used as a umbrella bug for Coverity issues in master
- branch unless you are trying to fix a specific bug in Bugzilla.
- - While sending patches for fixing Coverity issues please use the
- same bug number.
- - For 3.6 branch the Coverity tracking bug is
- [1122834](https://bugzilla.redhat.com/show_bug.cgi?id=1122834)
-- When you decide to work on some issue, please assign it to your name
- in the same Coverity website. So that we don't step on each others
- work.
-- When marking a bug intentional in Coverity scan website, please put
- an explanation for the same. So that it will help others to
- understand the reasoning behind it.
-
-*If you have more questions please send it to
-[gluster-devel](http://www.gluster.org/interact/mailinglists) mailing
-list*
-
-### CPP Check
-
-Cppcheck is available in Fedora and EL's EPEL repo
-
-- Install Cppcheck
-
- yum install cppcheck
-
-- Clone GlusterFS code
-
- git clone https://github.com/gluster/glusterfs) glusterfs
-
-- Run Cpp check
-
- cppcheck glusterfs/ 2>cppcheck.log
-
-- [BZ 1091677](https://bugzilla.redhat.com/show_bug.cgi?id=1091677)
- should be used for submitting patches to master branch for Cppcheck
- reported issues.
-
-### Daily Runs
-
-We now have daily runs of various static source code analysis tools on
-the glusterfs sources. There are daily analyses of the master,
-release-3.6, and release-3.5 branches.
-
-Results are posted at
-<http://download.gluster.org/pub/gluster/glusterfs/static-analysis/>
diff --git a/doc/developer-guide/GlusterFS-Release-process.md b/doc/developer-guide/GlusterFS-Release-process.md
deleted file mode 100644
index 504b012..0000000
--- a/doc/developer-guide/GlusterFS-Release-process.md
+++ /dev/null
@@ -1,73 +0,0 @@
-Release Process for GlusterFS
-=============================
-
-Create tarball
---------------
-
-1. Add the release-notes to the docs/release-notes/ directory in the
- sources
-2. after merging the release-notes, create a tag like v3.6.2
-3. push the tag to git.gluster.org
-4. create the tarball with the [release job in
- Jenkins](http://build.gluster.org/job/release/)
-
-Notify packagers
-----------------
-
-Notify the packagers that we need packages created. Provide the link to the
-source tarball from the Jenkins release job to the [packagers
-mailinglist](mailto:packaging@gluster.org). A list of the people involved in
-the package maintenance for the different distributions is in the `MAINTAINERS`
-file in the sources.
-
-Create a new Tracker Bug for the next release
----------------------------------------------
-
-The tracker bugs are used as guidance for blocker bugs and should get created when a release is made. To create one
-
-- file a [new bug in Bugzilla](https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS)
-- base the contents on previous tracker bugs, like the one for [glusterfs-3.5.5](https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.5.5)
-- set the '''Alias''' (it is a text-field) of the bug to 'glusterfs-a.b.c' where a.b.c is the next minor version
-- save the new bug
-- you should now be able to use the 'glusterfs-a.b.c' to access the bug, use the alias to replace the BZ# in URLs, or '''blocks''' fields
-- bugs that were not fixed in this release, but were added to the tracker should be moved to the new tracker
-
-
-Create Release Announcement
----------------------------
-
-Create the Release Announcement (this is often done while people are
-making the packages). The contents of the release announcement can be
-based on the release notes, or should at least have a pointer to them.
-
-Examples:
-
-- [blog](http://blog.gluster.org/2014/11/glusterfs-3-5-3beta2-is-now-available-for-testing/)
-- [release
- notes](https://github.com/gluster/glusterfs/blob/v3.5.3/doc/release-notes/3.5.3.md)
-
-Send Release Announcement
--------------------------
-
-Once the Fedora/EL RPMs are ready (and any others that are ready by
-then), send the release announcement:
-
-- Gluster Mailing lists
- - gluster-announce, gluster-devel, gluster-users
-- Gluster Blog
-- Gluster Twitter account
-- Gluster Facebook page
-- Gluster LinkedIn group - Justin has access
-- Gluster G+
-
-Close Bugs
-----------
-
-Close the bugs that have all their patches included in the release.
-Leave a note in the bug report with a pointer to the release
-announcement.
-
-Other things to consider
-------------------------
-
-- Translations? - Are there strings needing translation?
diff --git a/doc/developer-guide/Guidelines-For-Maintainers.md b/doc/developer-guide/Guidelines-For-Maintainers.md
deleted file mode 100644
index 71612cf..0000000
--- a/doc/developer-guide/Guidelines-For-Maintainers.md
+++ /dev/null
@@ -1,70 +0,0 @@
-### Guidelines For Maintainers
-
-GlusterFS has maintainers, sub-maintainers and release maintainers to
-manage the project's codebase. Sub-maintainers are the owners for
-specific areas/components of the source tree. Maintainers operate across
-all components in the source tree.Release maintainers are the owners for
-various release branches (release-x.y) present in the GlusterFS
-repository.
-
-In the guidelines below, release maintainers and sub-maintainers are
-also implied when there is a reference to maintainers unless it is
-explicitly called out.
-
-### Guidelines that Maintainers are expected to adhere to
-
-​1. Ensure qualitative and timely management of patches sent for review.
-
-​2. For merging patches into the repository, it is expected of
-maintainers to:
-
- a> Merge patches of owned components only.
- b> Seek approvals from all maintainers before merging a patchset spanning multiple components.
- c> Ensure that regression tests pass for all patches before merging.
- d> Ensure that regression tests accompany all patch submissions.
- e> Ensure that documentation is updated for a noticeable change in user perceivable behavior or design.
- f> Encourage code unit tests from patch submitters to improve the overall quality of the codebase.
- g> Not merge patches written by themselves until there is a +2 Code Review vote by other reviewers.
-
-​3. The responsibility of merging a patch into a release branch in
-normal circumstances will be that of the release maintainer's. Only in
-exceptional situations, maintainers & sub-maintainers will merge patches
-into a release branch.
-
-​4. Release maintainers will ensure approval from appropriate
-maintainers before merging a patch into a release branch.
-
-​5. Maintainers have a responsibility to the community, it is expected
-of maintainers to:
-
- a> Facilitate the community in all aspects.
- b> Be very active and visible in the community.
- c> Be objective and consider the larger interests of the community  ahead of individual interests.
- d> Be receptive to user feedback.
- e> Address concerns & issues affecting users.
- f> Lead by example.
-
-### Queries on Guidelines
-
-Any questions or comments regarding these guidelines can be routed to
-gluster-devel at gluster dot org.
-
-### Patches in Gerrit
-
-Gerrit can be used to list patches that need reviews and/or can get
-merged. Some queries have been prepared for this, edit the search box in
-Gerrit to make your own variation:
-
-- [3.5 open reviewed/verified (non
- rfc)](http://review.gluster.org/#/q/project:glusterfs+branch:release-3.5+status:open+%28label:Code-Review%253D%252B1+OR+label:Code-Review%253D%252B2+OR+label:Verified%253D%252B1%29+NOT+topic:rfc+NOT+label:Code-Review%253D-2,n,z)
-- [All open 3.5 patches (non
- rfc)](http://review.gluster.org/#/q/project:glusterfs+branch:release-3.5+status:open+NOT+topic:rfc,n,z)
-- [Open NFS (master
- branch)](http://review.gluster.org/#/q/project:glusterfs+branch:master+status:open+message:nfs,n,z)
-
-An other option can be used in combination with the Gerrit queries, and
-has support for filename/directory matching (the queries above do not).
-Go to the [settings](http://review.gluster.org/#/settings/projects) in
-your Gerrit profile, and enter filters like these:
-
-![gerrit-watched-projects](https://cloud.githubusercontent.com/assets/10970993/7411584/1a26614a-ef57-11e4-99ed-ee96af22a9a1.png)
diff --git a/doc/developer-guide/Jenkins-Infrastructure.md b/doc/developer-guide/Jenkins-Infrastructure.md
deleted file mode 100644
index cb5d63e..0000000
--- a/doc/developer-guide/Jenkins-Infrastructure.md
+++ /dev/null
@@ -1,127 +0,0 @@
-We're using Gerrit and [Jenkins](http://jenkins-ci.org) at the moment.
-Our Gerrit instance:
-
-http://review.gluster.org
-
-It's hosted on an ancient VM (badly needs upgrading) in some hosting
-place called iWeb. We're wanting to migrate this to a Rackspace VM in
-the very near future.
-
-Our main Jenkins instance:
-
-http://build.gluster.org
-
-That's also a pretty-out-of-date version of Jenkins, on an badly
-outdated VM. That one's in Rackspace at least. We intend on migrating to
-a new VM (and new Jenkins) in the not-too-far-future. No ETA yet. ;)
-
-As well as those two main pieces, we have a bunch of VM's in Rackspace
-with various OS's on them:
-
-http://build.gluster.org/computer/
-
-In that list we have:
-
-- bulk\*.cloud.gluster.org\
-
- - Temporary VM's used for running bulk regression tests on, for
- analysing our spurious regression failure problem
- - Setup and maintained by Justin Clift
-
-- freebsd0.cloud.gluster.org\
-
- - FreeBSD 10.0 VM in Rackspace. Used for automatic smoke testing
- on FreeBSD of all proposed patches (uses a Gerrit trigger).
-
-- g4s-rackspace-\* (apart from gfs-rackspace-f20-1), and
- tiny-rackspace-f20-1\
-
- - Various VM's in Rackspace with Fedora and EL6 on them, setup by
- Luis Pabon. From their description in Jenkins, they're nodes for
- "open-stack swift executing functional test suite against
- Gluster-for-Swift".
-
-- gfs-rackspace-f20-1\
-
- - A VM in Rackspace for automatically building RPMs on. Setup +
- maintained by Luis Pabon.
-
-- netbsd0.cloud.gluster.org\
-
- - NetBSD 6.1.4 VM in Rackspace. Used for automatic smoke testing
- on NetBSD 6.x of all proposed patches (uses a Gerrit trigger).
- - Setup and maintained by Manu Dreyfus
-
-- netbsd7.cloud.gluster.org\
-
- - NetBSD 7 (beta) VM in Rackspace. Used for automatic smoke
- testing on NetBSD 7 of all proposed patches (uses a Gerrit
- trigger).
- - Setup and maintained by Manu Dreyfus
-
-- nbslave7\*.cloud.gluster.org\
-
- - NetBSD 7 slaves VMs for running our regression tests on
- - Setup and maintained by Manu Dreyfus
-
-- slave20.cloud.gluster.org - slave49.cloud.gluster.org\
-
- - CentOS 6.5 VM's in Rackspace. Used for automatic regression
- testing of all proposed patches (uses a Gerrit trigger).
- - Setup and maintained by Michael Scherer
-
-Work is being done on the GlusterFS regression tests so they'll function
-on FreeBSD and NetBSD (instead of just Linux). When that's complete,
-we'll automatically run full regression testing on FreeBSD and NetBSD
-for all proposed patches too.
-
-Non Jenkins VMs
----------------
-
-**backups.cloud.gluster.org**
-
- Server holding our nightly backups. Setup and maintained by Michael
- Scherer.
-
-**bareos-dev.cloud.gluster.org, bareos-data.cloud.gluster.org**
-
- Shared VMs to debug Bareos and libgfapi integration. Maintained by
- Niels de Vos.
-
-**bugs.cloud.gluster.org**
-
- Hosting
- [gluster-bugs-webui](https://github.com/gluster/gluster-bugs-webui)
- for bug triage/checking. Maintained by Niels de Vos.
-
-**docs.cloud.gluster.org**
-
- Documentation server, running readTheDocs - managed by Soumya Deb.
-
-**download.gluster.org**
-
- Our primary download server - holds the Gluster binaries we
- generate, which people can download.
-
-**gluster-sonar**
-
- Hosts our Gluster
- [SonarQube](http://sonar.peircean.com/dashboard/index/com.peircean.glusterfs:glusterfs-java-filesystem)
- instance. Setup and maintained by Louis Zuckerman.
-
-**salt-master.gluster.org**
-
- Our Configuration Mgmt master VM. Maintained by Michael Scherer.
-
-**munin.gluster.org**
-
- Munin master. Maintained by Michael Scherer.
-
-**webbuilder.gluster.org**
-
- Our builder for the website. Maintained by Michael Scherer.
-
-**www.gluster.org aka supercolony.gluster.org**
-
- The main website server. Maintained by Michael Scherer, Justin
- Clift, Others ( add your name )
diff --git a/doc/developer-guide/Jenkins-Manual-Setup.md b/doc/developer-guide/Jenkins-Manual-Setup.md
deleted file mode 100644
index 3622c72..0000000
--- a/doc/developer-guide/Jenkins-Manual-Setup.md
+++ /dev/null
@@ -1,146 +0,0 @@
-Setting up Jenkins slaves on Rackspace for GlusterFS regression testing
-=======================================================================
-
-This is for RHEL/CentOS 6.x. The below commands should be run as root.
-
-### Install additional required packages
-
- yum -y install cmockery2-devel dbench libacl-devel mock nfs-utils yajl perl-Test-Harness salt-minion
-
-### Enable yum-cron for automatic rpm updates
-
- chkconfig yum-cron on
-
-### Add the mock user
-
- useradd -g mock mock
-
-### Disable eth1
-
-Because GlusterFS can fail if more than 1 ethernet interface
-
- sed -i 's/ONBOOT=yes/ONBOOT=no/' /etc/sysconfig/network-scripts/ifcfg-eth1
-
-### Disable IPv6
-
-As per <https://access.redhat.com/site/node/8709>
-
- sed -i 's/IPV6INIT=yes/IPV6INIT=no/' /etc/sysconfig/network-scripts/ifcfg-eth0
- echo 'options ipv6 disable=1' > /etc/modprobe.d/ipv6.conf
- chkconfig ip6tables off
- sed -i 's/NETWORKING_IPV6=yes/NETWORKING_IPV6=no/' /etc/sysconfig/network
- echo ' ' >> /etc/sysctl.conf
- echo '# ipv6 support in the kernel, set to 0 by default' >> /etc/sysctl.conf
- echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf
- echo 'net.ipv6.conf.default.disable_ipv6 = 1' >> /etc/sysctl.conf
- sed -i 's/v     inet6/-     inet6/' /etc/netconfig
-
-### Update hostname
-
- vi /etc/sysconfig/network
- vi /etc/hosts
-
-### Remove IPv6 and eth1 interface from /etc/hosts
-
- sed -i 's/^10\./#10\./' /etc/hosts
- sed -i 's/^2001/#2001/' /etc/hosts
-
-### Install ntp
-
- yum -y install ntp
- chkconfig ntpdate on
- service ntpdate start
-
-### Install OpenJDK, needed for Jenkins slaves
-
- yum -y install java-1.7.0-openjdk
-
-### Create the Jenkins user
-
- useradd -G wheel jenkins
- chmod 755 /home/jenkins
-
-### Set the Jenkins password
-
- passwd jenkins
-
-### Copy the Jenkins SSH key from build.gluster.org
-
- mkdir /home/jenkins/.ssh
- chmod 700 /home/jenkins/.ssh
- cp `<somewhere>` /home/jenkins/.ssh/id_rsa
- chown -R jenkins:jenkins /home/jenkins/.ssh
- chmod 600 /home/jenkins/.ssh/id_rsa
-
-### Generate the SSH known hosts file for jenkins user
-
- su - jenkins
- mkdir ~/foo
- cd ~/foo
- git clone `[`ssh://build@review.gluster.org/glusterfs.git`](ssh://build@review.gluster.org/glusterfs.git)
- (this will ask if the new host fingerprint should be added.  Choose yes)
- cd ..
- rm -rf ~/foo
-  exit
-
-### Install git from RPMForge
-
- yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
- yum -y --enablerepo=rpmforge-extras update git
-
-### Install the GlusterFS patch acceptance tests
-
- git clone git://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests.git /opt/qa
-
-### Add the loopback mount point to /etc/fstab
-
-For the 1GB Rackspace VM's use this:
-
- echo '/backingstore           /d                      xfs     loop            0 2' >> /etc/fstab
- mount /d
-
-For the 2GB and above Rackspace VM's use this:
-
- echo '/dev/xvde   /d   xfs   defaults   0 2' >> /etc/fstab
- mount /d
-
-### Create the directories needed for the regression testing
-
- JDIRS="/var/log/glusterfs /var/lib/glusterd /var/run/gluster /d /d/archived_builds /d/backends /d/build /d/logs /home/jenkins/root"
- mkdir -p $JDIRS
- chown jenkins:jenkins $JDIRS
- chmod 755 $JDIRS
- ln -s /d/build /build
-
-### Create the directories where regression logs are archived
-
- ADIRS="/archives/archived_builds /archives/logs"
- mkdir -p $ADIRS
- chown jenkins:jenkins $ADIRS
- chmod 755 $ADIRS
-
-### Install Nginx
-
-For making logs available over http
-
- yum -y install http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
- yum -y install nginx
- lokkit -s http
-
-### Copy the Nginx config file into place
-
- cp -f /opt/qa/nginx/default.conf /etc/nginx/conf.d/default.conf
-
-### Enable wheel group for sudo
-
- sed -i 's/# %wheel\tALL=(ALL)\tNOPASSWD/%wheel\tALL=(ALL)\tNOPASSWD/' /etc/sudoers
-
-### Reboot (for networking changes to take effect)
-
- reboot
-
-### Add forward and reverse DNS entries for the slave into Rackspace DNS
-
-Rackspace recently added [API calls for its Cloud
-DNS](https://developer.rackspace.com/docs/cloud-dns/getting-started/?lang=python)
-service, so we should be able to fully automate this part as well now. \ No newline at end of file
diff --git a/doc/developer-guide/Projects.md b/doc/developer-guide/Projects.md
deleted file mode 100644
index 5c41fef..0000000
--- a/doc/developer-guide/Projects.md
+++ /dev/null
@@ -1,99 +0,0 @@
-This page contains a list of project ideas which will be suitable for
-students (for GSOC, internship etc.)
-
-Projects with mentors
----------------------
-
-### gfsck - A GlusterFS filesystem check
-
-- A tool to check filesystem integrity and repairing
-- I'm currently working on it
-- Owner: Xavier Hernandez (Datalab)
-
-### Sub-directory mount support for native GlusterFS mounts
-
-Allow clients to directly mount directories inside a GlusterFS volume,
-like how NFS clients can mount directories inside an NFS export.
-
-Mentor: Kaushal <kshlmster at gmail dot com>
-
-### GlusterD services high availablity
-
-GlusterD should restart the processes it manages, bricks, nfs server,
-self-heal daemon and quota daemon, whenever it detects they have died.
-
-Mentor : Atin Mukherjee <atin.mukherjee83@gmail.com>
-
-### Language bindings for libgfapi
-
-- API/library for accessing gluster volumes
-
-### oVirt gui for stats
-
-Have pretty graphs and tables in ovirt for the GlusterFS top and profile
-commands.
-
-### Monitoring integrations - munin others
-
-The more monitoring support we have for GlusterFS the better.
-
-### More compression algorithms for compression xlator
-
-The on-wire compression translator should be extended to support more
-compression algorithms. Ideally it should be pluggable.
-
-### Cinder GlusterFS backup driver
-
-Write a driver for cinder, a part of openstack, to allow backup onto
-GlusterFS volumes
-
-### rsockets - sockets for rdma transport
-
-Coding for RDMA using the familiar socket api should lead to a more
-robust rdma transport
-
-### Data import tool
-
-Create a tool which will allow importing already existing data in the
-brick directories into the gluster volume. This is most likely going to
-be a special rebalance process.
-
-### Rebalance improvements
-
-Improve rebalance performance.
-
-### Meta translator
-
-The meta xlator provides a /proc like interface to GlusterFS xlators.
-This could be improved upon and the meta xlator could be made a standard
-part of the volume graph.
-
-### Geo-replication using rest-api
-
-Might be suitable for geo replication over WAN.
-
-### Quota using underlying FS' quota
-
-GlusterFS quota is currently maintained completely in GlusterFSs
-namespace using xattrs. We could make use of the quota capabilities of
-the underlying fs (XFS) for better performance.
-
-### Snapshot pluggability
-
-Snapshot should be able to make use of snapshot support provided by
-btrfs for example.
-
-### Compression at rest
-
-Lessons learnt while implementing encryption at rest can be used with
-the compression at rest.
-
-### File-level deduplication
-
-GlusterFS works on files. So why not have dedup at the level files as
-well.
-
-### Composition xlator for small files
-
-Merge small files into a designated large file using our own custom
-semantics. This can improve our small file performance. \ No newline at end of file
diff --git a/doc/developer-guide/Simplified-Development-Workflow.md b/doc/developer-guide/Simplified-Development-Workflow.md
deleted file mode 100644
index c95e3ba..0000000
--- a/doc/developer-guide/Simplified-Development-Workflow.md
+++ /dev/null
@@ -1,238 +0,0 @@
-Simplified development workflow for GlusterFS
-=============================================
-
-This page gives a simplified model of the development workflow used by
-the GlusterFS project. This will give the steps required to get a patch
-accepted into the GlusterFS source.
-
-Visit [Development Work Flow](./Development Workflow.md) a more
-detailed description of the workflow.
-
-Initial preperation
--------------------
-
-The GlusterFS development workflow revolves around
-[Git](http://git.gluster.org/?p=glusterfs.git;a=summary),
-[Gerrit](http://review.gluster.org) and
-[Jenkins](http://build.gluster.org).
-
-Using these tools requires some initial preparation.
-
-### Dev system setup
-
-You should install and setup Git on your development system. Use your
-distribution specific package manger to install git. After installation
-configure git. At the minimum, set a git user email. To set the email
-do,
-
- $ git config --global user.name "Name"
- $ git config --global user.email <email address>
-
-You should also generate an ssh key pair if you haven't already done it.
-To generate a key pair do,
-
- $ ssh-keygen
-
-and follow the instructions.
-
-Next, install the build requirements for GlusterFS. Refer
-[Building GlusterFS - Build Requirements](./Building GlusterFS.md#Build Requirements)
-for the actual requirements.
-
-### Gerrit setup
-
-To contribute to GlusterFS, you should first register on
-[gerrit](http://review.gluster.org).
-
-After registration, you will need to select a username, set a preferred
-email and upload the ssh public key in gerrit. You can do this from the
-gerrit settings page. Make sure that you set the preferred email to the
-email you configured for git.
-
-### Get the source
-
-Git clone the GlusterFS source using
-
- <ssh://><username>@review.gluster.org/glusterfs.git
-
-(replace <username> with your gerrit username).
-
- $ git clone (ssh://)<username> @review.gluster.org/glusterfs.git
-
-This will clone the GlusterFS source into a subdirectory named glusterfs
-with the master branch checked out.
-
-It is essential that you use this link to clone, or else you will not be
-able to submit patches to gerrit for review.
-
-Actual development
-------------------
-
-The commands in this section are to be run inside the glusterfs source
-directory.
-
-### Create a development branch
-
-It is recommended to use separate local development branches for each
-change you want to contribute to GlusterFS. To create a development
-branch, first checkout the upstream branch you want to work on and
-update it. More details on the upstream branching model for GlusterFS
-can be found at
-
-[Development Work Flow - Branching\_policy](./Development Workflow.md#branching-policy).
-For example if you want to develop on the master branch,
-
- $ git checkout master
- $ git pull
-
-Now, create a new branch from master and switch to the new branch. It is
-recommended to have descriptive branch names. Do,
-
- $ git branch <descriptive-branch-name>
- $ git checkout <descriptive-branch-name>
-
-or,
-
- $ git checkout -b <descriptive-branch-name>
-
-to do both in one command.
-
-### Hack
-
-Once you've switched to the development branch, you can perform the
-actual code changes. [Build](./Building GlusterFS) and test to
-see if your changes work.
-
-#### Tests
-
-Unless your changes are very minor and trivial, you should also add a
-test for your change. Tests are used to ensure that the changes you did
-are not broken inadvertently. More details on tests can be found at
-
-[Development Workflow - Test cases](./Development Workflow.md#test-cases)
-and
-[Development Workflow - Regression tests and test cases](./Development Workflow.md#regression-tests-and-test-cases)
-
-### Regression test
-
-Once your change is working, run the regression test suite to make sure
-you haven't broken anything. The regression test suite requires a
-working GlusterFS installation and needs to be run as root. To run the
-regression test suite, do
-
- # make install
- # ./run-tests.sh
-
-### Commit your changes
-
-If you haven't broken anything, you can now commit your changes. First
-identify the files that you modified/added/deleted using git-status and
-stage these files.
-
- $ git status
- $ git add <list of modified files>
-
-Now, commit these changes using
-
- $ git commit -s
-
-Provide a meaningful commit message. The commit message policy is
-described at
-
-[Development Work Flow - Commit policy](./Development Workflow.md#commit-policy).
-
-It is essential that you commit with the '-s' option, which will
-sign-off the commit with your configured email, as gerrit is configured
-to reject patches which are not signed-off.
-
-### Submit for review
-
-To submit your change for review, run the rfc.sh script,
-
- $ ./rfc.sh
-
-The script will ask you to enter a bugzilla bug id. Every change
-submitted to GlusterFS needs a bugzilla entry to be accepted. If you do
-not already have a bug id, file a new bug at [Red Hat
-Bugzilla](https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS).
-If the patch is submitted for review, the rfc.sh script will return the
-gerrit url for the review request.
-
-More details on the rfc.sh script are available at
-[Development Work Flow - rfc.sh](./Development Workflow.md#rfc.sh).
-
-Review process
---------------
-
-Your change will now be reviewed by the GlusterFS maintainers and
-component owners on [gerrit](http://review.gluster.org). You can follow
-and take part in the review process on the change at the review url. The
-review process involves several steps.
-
-To know component owners , you can check the "MAINTAINERS" file in root
-of glusterfs code directory
-
-### Automated verification
-
-Every change submitted to gerrit triggers an initial automated
-verification on [jenkins](http://build.gluster.org). The automated
-verification ensures that your change doesn't break the build and has an
-associated bug-id.
-
-More details can be found at
-
-[Development Work Flow - Auto verification](./Development Workflow.md#auto-verification).
-
-### Formal review
-
-Once the auto verification is successful, the component owners will
-perform a formal review. If they are okay with your change, they will
-give a positive review. If not they will give a negative review and add
-comments on the reasons.
-
-More information regarding the review qualifiers and disqualifiers is
-available at
-
-[Development Work Flow - Submission Qualifiers](./Development Workflow.md#submission-qualifiers)
-and
-[Development Work Flow - Submission Disqualifiers](./Development Workflow.md#submission-disqualifiers).
-
-If your change gets a negative review, you will need to address the
-comments and resubmit your change.
-
-#### Resubmission
-
-Switch to your development branch and make new changes to address the
-review comments. Build and test to see if the new changes are working.
-
-Stage your changes and commit your new changes using,
-
- $ git commit --amend
-
-'--amend' is required to ensure that you update your original commit and
-not create a new commit.
-
-Now you can resubmit the updated commit for review using the rfc.sh
-script.
-
-The formal review process could take a long time. To increase chances
-for a speedy review, you can add the component owners as reviewers on
-the gerrit review page. This will ensure they notice the change. The
-list of component owners can be found in the MAINTAINERS file present in
-the GlusterFS source
-
-### Verification
-
-After a component owner has given a positive review, a maintainer will
-run the regression test suite on your change to verify that your change
-works and hasn't broken anything. This verification is done with the
-help of jenkins.
-
-If the verification fails, you will need to make necessary changes and
-resubmit an updated commit for review.
-
-### Acceptance
-
-After successful verification, a maintainer will merge/cherry-pick (as
-necessary) your change into the upstream GlusterFS source. Your change
-will now be available in the upstream git repo for everyone to use. \ No newline at end of file