~markwright/scalestack/zeromq

« back to all changes in this revision

Viewing changes to README

  • Committer: Eric Day
  • Date: 2010-02-21 10:36:03 UTC
  • Revision ID: eday@oddments.org-20100221103603-u0agc1fsduqhl728
Initial commit with build system and basic module loading.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
#
 
2
# Scale Stack
 
3
#
 
4
# Copyright (C) 2010 Eric Day (eday@oddments.org)
 
5
# All rights reserved.
 
6
#
 
7
# Use and distribution licensed under the BSD license. See the
 
8
# COPYING file in the root project directory for full text.
 
9
#
 
10
 
 
11
Welcome!
 
12
--------
 
13
 
 
14
If you're reading this you probably have some idea what this project
 
15
is all about, but if not, check out http://scalestack.org/ for more
 
16
details. The website covers motivation and design principals for the
 
17
project, as well as more detailed use cases and application-specific
 
18
documentation. This document focuses on the basics of getting started
 
19
and how to contribute to the project. If you simply want to use the
 
20
software from a tarball distribution, getting started is as simple as:
 
21
 
 
22
./configure
 
23
make
 
24
make install
 
25
 
 
26
If you checked this out from Launchpad, you'll want to run the
 
27
following command first, and then the above commands:
 
28
 
 
29
./config/autorun.sh
 
30
 
 
31
 
 
32
Resources
 
33
---------
 
34
 
 
35
Website: http://scalestack.org/
 
36
Project: https://launchpad.net/scalestack
 
37
IRC: #scalestack on irc.freenode.net
 
38
Mailing list: https://launchpad.net/~scalestack-dev
 
39
 
 
40
 
 
41
Contributing
 
42
------------
 
43
 
 
44
All code is licensed under BSD, and all contributions will be taken
 
45
under that license as well. Other licenses may be considered for
 
46
self-contained modules. No copyright assignment is needed, you (or
 
47
your employer) own your work. :)
 
48
 
 
49
To get started fixing bugs, improving existing modules, or adding
 
50
new modules, you'll want to register an account with Launchpad and
 
51
check out the source. This also requires having the Bazaar VCS (bzr)
 
52
installed. See https://help.launchpad.net/ for more details on the
 
53
Launchpad development process, but here is a crash-course. Once you
 
54
have an account and have setup your SSH key, tell bzr about it. This
 
55
only needs to be run once:
 
56
 
 
57
bzr lp-login johndoe
 
58
bzr whoami "John Doe <johndoe@somewhere.com>"
 
59
 
 
60
To create a local repository and check out the trunk, run:
 
61
 
 
62
bzr init-repo scalestack
 
63
cd scalestack
 
64
bzr branch lp:scalestack
 
65
 
 
66
You now have a shared repository and the trunk. You generally never
 
67
want to make changes to trunk directly, so to start making changes,
 
68
create a branch:
 
69
 
 
70
bzr branch scalestack my-changes
 
71
cd my-changes
 
72
 
 
73
This will create another branch, my-changes, in the shared repository
 
74
directory. Make your changes there and commit them (remember to add
 
75
any new files). Once you think you have something ready to share, push
 
76
your branch back up to Launchpad (which requires a Launchpad account).
 
77
 
 
78
bzr add <new files>
 
79
bzr commit -m "Comment describing my changes"
 
80
bzr push lp:~johndoe/scalestack/my-changes
 
81
 
 
82
You can the propose your branch for merging into trunk on the Launchpad
 
83
project page. This can be done on your branch page which you can find
 
84
linked from:
 
85
 
 
86
https://code.launchpad.net/scalestack
 
87
 
 
88
If you would like to add new modules, please do so in the ScaleStack
 
89
directory. The C++ namespace is directly translated to path names
 
90
there, so you'll find all code in that directory. Look around at the
 
91
other modules for examples on how to do so, but the minimum needed
 
92
is a plugin.ini and <Module Name>.cc file. Reading the documentation
 
93
in ScaleStack/Module.h may be helpful as well.
 
94
 
 
95
 
 
96
Coding Style Guidelines
 
97
-----------------------
 
98
 
 
99
For the sake of brevity, the guidelines will follow the Google style
 
100
except for where it is immediately obvious in the code, and the cases
 
101
mentioned below:
 
102
 
 
103
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
 
104
 
 
105
Exceptions to this guide include:
 
106
 
 
107
* Comments should follow Doxygen style formatting. See existing code
 
108
  for examples.
 
109
* Opening curly braces will appear on their own line.
 
110
* C++ exceptions are used, and all custom exceptions should derive
 
111
  from std::exception.
 
112
* Public method names should be camelCase starting with lower.
 
113
* Private method names should be _camelCase starting with underscore
 
114
  and lower.
 
115
* Data members should always be private, and are all lower with
 
116
  underscores, such as number_of_connections.
 
117
 
 
118
As always, these rules are up for redefining, please bring any issues
 
119
to light on the mailing list. :)