From cc91486f8a3619a61e803d990284b040797a1944 Mon Sep 17 00:00:00 2001 From: mathieui Date: Sat, 7 Feb 2015 20:34:04 +0100 Subject: Move README to README.rst reformat minor stuff, and update the links to the chatroom --- README | 165 ---------------------------------------------------------- README.rst | 172 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 172 insertions(+), 165 deletions(-) delete mode 100644 README create mode 100644 README.rst diff --git a/README b/README deleted file mode 100644 index 070fd713..00000000 --- a/README +++ /dev/null @@ -1,165 +0,0 @@ - - _ - (_) - _ __ ___ ___ _____ ___ - | '_ \ / _ \ / _ \_ / |/ _ \ - | |_) | (_) | __// /| | (_) | - | .__/ \___/ \___/___|_|\___/ - | | - |_| - -Homepage: http://poez.io -Forge Page: http://dev.poez.io - -Poezio is a console Jabber/XMPP client. Its goal is to use anonymous -connections to simply let the user join MultiUserChats. This way, the user -doesn't have to create a Jabber account, exactly like people are using -IRC. Poezio's commands are designed to be (if possible) like commonly -used IRC clients (weechat, irssi, etc). - -Since version 0.7, poezio can handle real Jabber accounts along with -roster and one-to-one conversations, making it a full-featured console -Jabber client, but still MultiUserChats-centered. -In the future, poezio should implement at a 100% level all XEP related to -MUCs, especially XEP 0045. - -======================= - Install -======================= - -You need python 3.4 or higher (preferably the latest) and the associated devel -package, to build C modules, and the slixmpp python library. -You also need aiodns if you want SRV record support. - -Additionally, you’ll need sphinx to build the documentation pages. -To read the documentation without these dependancies just read the rst -files in the doc/source/ directory or the generated documentation on the -website. - -The simplest way to have up-to-date dependencies and to be able to test -this developement version is to use the update.sh script that downloads -and places them in the right directory. - -You also need to compile some external C modules, to do this, just enter - -$ make - -you can then launch poezio with - -$ ./launch.sh - -or you can install it with (as root or with sudo) - -$ make install - -(`make uninstall' works, don't worry ;)) -you can now simply launch `poezio' - -You can edit the configuration file which is located in -~/.config/poezio/poezio.cfg by default, and you will have to edit -data/default_config.cfg if you want to edit the config before the -first launch. The default config file is fully commented, but you can -also read the “Configuration” documentation page which has links between -options and longer descriptions. - -Please see the online documentation for more information on installing, -configuring or using poezio: -http://doc.poez.io/ - -If you still have questions, or if you're lost, don't hesitate to come -talk to us directly on our Jabber chat room (see Contact section). - -Please DO report any bug you encounter and ask for any feature you want -(we may implement it or not, but it’s always better to ask). - -======================= - Authors -======================= -Florent Le Coz (louiz’) (developer) -Mathieu Pasquet (mathieui) (developer) - - -======================= - Contact/support -======================= -Jabber ChatRoom: poezio@muc.poezio.eu -Report a bug: http://dev.poez.io/new - -======================= - License -======================= -Poezio is Free Software. -(learn more: http://www.gnu.org/philosophy/free-sw.html) - -Poezio is released under the zlib License. -Please read the COPYING file for details. - -The artwork logo was made by Gaëtan Ribémont and released under -the Creative Commons BY license (http://creativecommons.org/licenses/by/2.0/) - - -======================= - Hacking -======================= - -If you want to contribute, you are invited on poezio@muc.poezio.eu to -announce your ideas, what you are going to do, or to seek help if you -have trouble understanding some of the code. -The preferred way to submit changes is through a public git repository. -But mercurial repositories or simple patches are also welcome. - -For contributors having commit access: - -This section explains how the git repository is organized. -The “master” branch is the branch where all recent development is made. This is -the unstable version, which can be broken, but we should try to keep it usable -and crash-free as much as possible (so, never push to it if you are adding a -*known* crash). - -New big features that take time to be complete should be developed in feature -branches (for example the “plugins” or the “opt” branches). -If it’s a really long feature, merge the “master” branch in that feature branch -from time to time, to avoid huge merges (and merge issues) when you’ll have to -merge your feature back in “master”. -Merge your work in master once it works and is usable, not necessarily when -it’s 100% finished. Polishing and last bug fixes can take place in “master”. - -Conflicts should be solved with *rebase* and not with merge. This means -that if two developers commited one thing at the same time in their own -repository, the first pushes on the public public repos, and the other -has to pull before being able to push too. In that case, the second -developer should use the rebase command instead of merge. This avoids -creating unnecessary “branches” and visible merges. -On the contrary, when merging feature branches back to “master”, we should -use merge with the --no-ff tag (this makes sure the branch will always -distinctly appear in the logs), even if no conflict occured. - -Finally, when a release is ready, we should merge the “master” branch -into the releases branch, then tag it to that version number. -If an “urgent” bugfix has to be made for a release (for example -a security issue is discovered on the last stable version, and -the current master has evolved too much to be released in the current -state), we create a new bugfix branch from the “releases” branch, we fix -it and finally merge it back to the “releases” branch, and tag it (and -we merge it to “master” as well, of course). - - -======================= - Thanks -======================= - -= People = - - Todd Eisenberger (todd@teisen.be) - Plugin system and OTR support - - Jérôme Parment (Manfraid) - Code, testing - - Link Mauve - Code, testing - - Eijebong - Code - - Gaëtan Ribémont (http://www.bonbref.com) - Logo design - - Ovart - Testing - - Koshie - Donation - - Gapan - Makefile - - FlashCode (weechat dev) - Useful advices on how to use ncurses efficiently - - And all the people using and testing poezio, and especially the ones present - on the jabber chatroom doing bug reports and/or feature requests. -= Project = - Gajim - send_vcard method, common.py, and PEP listings - diff --git a/README.rst b/README.rst new file mode 100644 index 00000000..adc4e5c7 --- /dev/null +++ b/README.rst @@ -0,0 +1,172 @@ +:: + + _ + (_) + _ __ ___ ___ _____ ___ + | '_ \ / _ \ / _ \_ / |/ _ \ + | |_) | (_) | __// /| | (_) | + | .__/ \___/ \___/___|_|\___/ + | | + |_| + +Homepage: http://poez.io + +Forge Page: http://dev.poez.io + +Poezio is a console Jabber/XMPP client. Its goal is to use anonymous +connections to simply let the user join MultiUserChats. This way, the user +doesn't have to create a Jabber account, exactly like people are using +IRC. Poezio's commands are designed to be (if possible) like commonly +used IRC clients (weechat, irssi, etc). + +Since version 0.7, poezio can handle real Jabber accounts along with +roster and one-to-one conversations, making it a full-featured console +Jabber client, but still MultiUserChats-centered. +In the future, poezio should implement at a 100% level all XEP related to +MUCs, especially XEP 0045. + +======================= + Install +======================= + +You need python 3.4 or higher (preferably the latest) and the associated devel +package, to build C modules, and the slixmpp python library. +You also need aiodns if you want SRV record support. + +Additionally, you’ll need sphinx to build the documentation pages. +To read the documentation without these dependancies just read the rst +files in the doc/source/ directory or the generated documentation on the +website. + +The simplest way to have up-to-date dependencies and to be able to test +this developement version is to use the ``update.sh`` script that downloads +and places them in the right directory. + +You also need to compile some external C modules, to do this, just enter + +:: + + $ make + +you can then launch poezio with + +:: + + $ ./launch.sh + +you can now simply launch ``poezio`` + +You can edit the configuration file which is located in +``~/.config/poezio/poezio.cfg`` by default, and you will have to copy +and edit ``data/default_config.cfg`` if you want to edit the config before +the first launch. The default config file is fully commented, but you can +also read the “Configuration” documentation page which has links between +options and longer descriptions. + +Please see the online documentation for more information on installing, +configuring or using poezio: http://doc.poez.io/ + +If you still have questions, or if you're lost, don't hesitate to come +talk to us directly on our Jabber chat room (see Contact section). + +Please DO report any bug you encounter and ask for any feature you want +(we may implement it or not, but it’s always better to ask). + +======================= + Authors +======================= + +- Florent Le Coz (louiz’) (developer) +- Mathieu Pasquet (mathieui) (developer) + +======================= + Contact/support +======================= + +Jabber ChatRoom: `poezio@muc.poez.io `_ + +Report a bug: http://dev.poez.io/new + +======================= + License +======================= + +Poezio is Free Software. +(learn more: http://www.gnu.org/philosophy/free-sw.html) + +Poezio is released under the zlib License. +Please read the COPYING file for details. + +The artwork logo was made by Gaëtan Ribémont and released under +the Creative Commons BY license (http://creativecommons.org/licenses/by/2.0/) + + +======================= + Hacking +======================= + +If you want to contribute, you will be welcome on +`poezio@muc.poez.io `_ to announce your +ideas, what you are going to do, or to seek help if you have trouble +understanding some of the code. + +The preferred way to submit changes is through a public git repository. +But mercurial repositories or simple patches are also welcome. + +For contributors having commit access: + +This section explains how the git repository is organized. +The “master” branch is the branch where all recent development is made. This is +the unstable version, which can be broken, but we should try to keep it usable +and crash-free as much as possible (so, never push to it if you are adding a +*known* crash). + +New big features that take time to be complete should be developed in feature +branches (for example the “plugins” or the “opt” branches). +If it’s a really long feature, merge the “master” branch in that feature branch +from time to time, to avoid huge merges (and merge issues) when you’ll have to +merge your feature back in “master”. + +Merge your work in master once it works and is usable, not necessarily when +it’s 100% finished. Polishing and last bug fixes can take place in “master”. + +Conflicts should be solved with *rebase* and not with merge. This means +that if two developers commited one thing at the same time in their own +repository, the first pushes on the public public repos, and the other +has to pull before being able to push too. In that case, the second +developer should use the rebase command instead of merge. This avoids +creating unnecessary “branches” and visible merges. +On the contrary, when merging feature branches back to “master”, we should +use merge with the --no-ff tag (this makes sure the branch will always +distinctly appear in the logs), even if no conflict occured. + +Finally, when a release is ready, we should merge the “master” branch +into the releases branch, then tag it to that version number. +If an “urgent” bugfix has to be made for a release (for example +a security issue is discovered on the last stable version, and +the current master has evolved too much to be released in the current +state), we create a new bugfix branch from the “releases” branch, we fix +it and finally merge it back to the “releases” branch, and tag it (and +we merge it to “master” as well, of course). + + +======================= + Thanks +======================= + +- People: + - Todd Eisenberger - Plugin system and OTR support + - Jérôme Parment (Manfraid) - Code, testing + - Link Mauve - Code, testing + - Perdu - Code + - Eijebong - Code + - Gaëtan Ribémont (http://www.bonbref.com) - Logo design + - Ovart - Testing + - Koshie - Donation + - Gapan - Makefile + - FlashCode (weechat dev) - Useful advices on how to use ncurses efficiently + - And all the people using and testing poezio, and especially the ones present + on the jabber chatroom doing bug reports and/or feature requests. +- Project + - Gajim - send_vcard method, common.py, and PEP listings + -- cgit v1.2.3