|
|
@@ -6,8 +6,8 @@ different communities with different expectations and requirements, it is both
|
|
|
essential and difficult to have contributions from the communities. While they
|
|
|
are sometimes necessary to adapt Gluon to the needs of the communities, they
|
|
|
also have to be adaptable enough to fit as many needs as possible. On the other
|
|
|
-hands, very special needs are better addressed in packages in [community
|
|
|
-repositories], because the Gluon maintainers would not use or test them and
|
|
|
+hands, very special needs are better addressed in [packages] in community
|
|
|
+repositories, because the Gluon maintainers would not use or test them and
|
|
|
thus couldn't do their "job" of maintaining them.
|
|
|
|
|
|
To ease the work for the maintainers and to reduce the frustration of
|
|
|
@@ -25,10 +25,9 @@ after merging the changes, too.
|
|
|
|
|
|
The preferred way to discuss in the IRC channel ([#gluon] on irc.hackint.org)
|
|
|
or on the [mailing list], however, you can also open a new issue on Github to
|
|
|
-discuss there. We maintain a [list of rejected
|
|
|
-features](https://github.com/freifunk-gluon/gluon/issues?q=label%3Arejected)
|
|
|
-and we'd like to kindly ask you to review it first. In general, looking for
|
|
|
-duplicates may save you some time.
|
|
|
+discuss there. We maintain a [list of rejected features] and we'd like to
|
|
|
+kindly ask you to review it first. In general, looking for duplicates may save
|
|
|
+you some time.
|
|
|
|
|
|
Develop on top of master
|
|
|
------------------------
|
|
|
@@ -53,7 +52,7 @@ Most changes are trivial enough to fit in one single commit in order to not
|
|
|
clutter the history. While developing a new feature, you are free to use
|
|
|
multiple commits, but if your feature is to be merged, reduce the number of
|
|
|
commits to a minimum. Even huge feature introductions like the 802.11s mesh
|
|
|
-(commit 2a93c58) fit into a single commit.
|
|
|
+(commit [2a93c58]) fit into a single commit.
|
|
|
|
|
|
If you developed your change in multiple smaller commits, you can easily
|
|
|
[squash] those before opening the pull request. While discussing, it is okay to
|
|
|
@@ -62,7 +61,9 @@ the pull request. This way, your change always consists of only one commit and
|
|
|
can be merged in the instant everybody is content with the whole thing.
|
|
|
|
|
|
|
|
|
-[community repositories]: http://gluon.readthedocs.org/en/latest/user/site.html#packages
|
|
|
-[#gluon]: irc://irc.hackint.org/gluon
|
|
|
+[packages]: http://gluon.readthedocs.org/en/latest/user/site.html#packages
|
|
|
+[#gluon]: https://webirc.hackint.org/#gluon
|
|
|
[mailing list]: mailto:gluon@luebeck.freifunk.net
|
|
|
+[list of rejected features]: https://github.com/freifunk-gluon/gluon/issues?q=label%3Arejected
|
|
|
+[2a93c58]: https://github.com/freifunk-gluon/gluon/commit/2a93c580428d10724116b0d2d1238e2745715a14
|
|
|
[squash]: https://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Squashing-Commits
|
kb-light