nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs/hacking-howto: Promote "How to build?" sub-section 

Move the "How to build?" sub-section to the top of its parent section.
This commit is contained in:
Vladimir Panteleev 2017-09-11 13:06:40 +00:00
parent 5c693ec2ae
commit e799bda2da
No known key found for this signature in database
GPG Key ID: 5004F0FAD051576D
1 changed files with 37 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
docs/hacking-howto
View File

@ -10,43 +10,6 @@ you find necessary, please do not hesitate to contact me.
== Using git / sending patches
=== Introduction
For a short introduction into using git, see
http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy
or, for more documentation, see http://git-scm.com/documentation
Please talk to us before working on new features to see whether they will be
accepted. A good way for this is to open an issue and asking for opinions on it.
Even for accepted features, this can be a good way to refine an idea upfront. However,
we don't want to see certain features in i3, e.g., switching window focus in an
Alt+Tab like way.
When working on bugfixes, please make sure you mention that you are working on
it in the corresponding bug report at https://github.com/i3/i3/issues. In case
there is no bug report yet, please create one.
After you are done, please submit your work for review as a pull request at
https://github.com/i3/i3.
Do not send emails to the mailing list or any author directly, and don’t submit
them in the bugtracker, since all reviews should be done in public at
https://github.com/i3/i3. In order to make your review go as fast as possible, you
could have a look at previous reviews and see what the common mistakes are.
=== Which branch to use?
Work on i3 generally happens in two branches: “master” and “next” (the latter
being the default branch, the one that people get when they check out the git
repository).
The contents of “master” are always stable. That is, it contains the source code
of the latest release, plus any bugfixes that were applied since that release.
New features are only found in the “next” branch. Therefore, if you are working
on a new feature, use the “next” branch. If you are working on a bugfix, use the
“next” branch, too, but make sure your code also works on “master”.
=== How to build?
You can build i3 like you build any other software package which uses autotools.
@ -88,6 +51,43 @@ Here’s a memory refresher:
* Coverage reports are now generated using “make check-code-coverage”, which
requires specifying --enable-code-coverage when calling configure.
=== Introduction
For a short introduction into using git, see
http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy
or, for more documentation, see http://git-scm.com/documentation
Please talk to us before working on new features to see whether they will be
accepted. A good way for this is to open an issue and asking for opinions on it.
Even for accepted features, this can be a good way to refine an idea upfront. However,
we don't want to see certain features in i3, e.g., switching window focus in an
Alt+Tab like way.
When working on bugfixes, please make sure you mention that you are working on
it in the corresponding bug report at https://github.com/i3/i3/issues. In case
there is no bug report yet, please create one.
After you are done, please submit your work for review as a pull request at
https://github.com/i3/i3.
Do not send emails to the mailing list or any author directly, and don’t submit
them in the bugtracker, since all reviews should be done in public at
https://github.com/i3/i3. In order to make your review go as fast as possible, you
could have a look at previous reviews and see what the common mistakes are.
=== Which branch to use?
Work on i3 generally happens in two branches: “master” and “next” (the latter
being the default branch, the one that people get when they check out the git
repository).
The contents of “master” are always stable. That is, it contains the source code
of the latest release, plus any bugfixes that were applied since that release.
New features are only found in the “next” branch. Therefore, if you are working
on a new feature, use the “next” branch. If you are working on a bugfix, use the
“next” branch, too, but make sure your code also works on “master”.
== Window Managers
A window manager is not necessarily needed to run X, but it is usually used in