Sapidlib Project FAQ

PULLED FROM WEBSITE 03-JAN-08

/home /sapidlib /Project FAQ
FAQ Index

   1. Sapidlib? TMI-III? LPuniMudlib? What is the real name of this project?
   2. Who directs the project?
   3. Can you explain the hierarchy?
   4. Why do you have a hierarchy?
   5. How do I get involved?
   6. How do I get the latest code?
   7. How do I submit my changes?
   8. How do I ensure I don't commit unwanted changes?
   9. Why are there are so many different branches?
  10. How are branch permissions managed?
  11. How do I get shell access to Osunta?

Questions & Answers
1. Sapidlib? TMI-III? LPuniMudlib? What is the real name of this project?

The mudlib has gone through a number of different name changes for a number of different reasons. Recently (Dec 
2007), the mudlib project was renamed to "Sapidlib" - the original name of the mudlib.


2. Who directs the project?

The Sapidlib mudlib project is directed by the members of the Sapidlib Core Developer Team (sapidlib-dev-core) with 
Cody Somerville being the lead developer. It is desired to get general consensus from the people actually doing the 
work.


3. Can you explain the hierarchy?

The Sapidlib project has a very simple, linear hierarchy that is used to manage permissions and to help identify 
individuals who are trusted contributors.

   1. Core Developers
   2. Developers
   3. Casual contributors

Casuaul contributors are folks who contribute here and there usually by submitting patches, filing bug reports, and 
helping other users.

Developers are contributors who have proven themselves to be trustworthy, are looking to get more involved, and have 
a history of sustained contribution. Developers have further access on launchpad (such as being able to set the 
importance of bugs and upload rights to certian bazaar branches) as well as access to other tools/infrastructure 
helpful to developing the mudlib.

Core Developers are developers who have became big movers and shakers by taking on big projects, showing a 
consistency to produce high quality code, and are looking to have a leadership role within the project to some 
degree. Core developers have even more access on launchpad (such as being able to create series, make releases, and 
have commit access to our primary maineline development branch).


4. Why do you have a hierarchy?

Our project utilises the simple hierarchy described in FAQ #3 to lower the barrier to becoming a contributor. Instead 
of it being an all or nothing system, developers can get the appropriate access they need for the level of 
contribution they are willing to give.


5. How do I get involved?

We attempt to making getting involved as easy as possible but the answer to this question entirely depends on what 
you want to get involved with. For example, if you're interested in getting involved with coding or documentation, 
simply download the latest code and start editing and/or creating new content. You'll be able to create a patch which 
you can attach to a bug report asking for a developer to review. If you have an idea for contributing some other way, 
feel free to talk to a member of the core developer team about it.


6. How do I get the latest code?

Our project makes use of a revision control system called bazaar. To find out how to install this tool, visit 
http://bazaar-vcs.org/Download. For a quick tutorial, see: 
http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html. The user guide can be found at 
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html.

Our project has different "series" which represent releases (allowing us to maintain old releases or even seperate 
work for future releases). One of these series is called "trunk" which is the current development focus and will 
become the next release. Generally, the branch attached to the trunk contains the latest code. By visiting 
http://launchpad.net/sapidlib/trunk, you can find the link to the current development branch which actually gives you 
the commands you need to type (word for word) to download it (ex. bzr branch 
http://bazaar.launchpad.net/~sapidlib-dev-core/sapidlib/devel).

The mainline development branch is also exported nightly and placed in lpuni.org/nightly/.


7. How do I submit my changes?

Our project uses a model called "Decentralized with human gatekeeper". In this workflow, each developer has their own 
branch or branches, plus read-only access to the main branch (ie. the trunk). One developer (the gatekeeper) has 
commit rights to the main branch (in our cases, core developers). When a developer wants their work merged, they ask 
the gatekeeper to merge it. The gatekeeper does code review, and merges the work into the main branch if it meets the 
necessary standards.

You can either generate a patch (type "bzr help diff" to see how to create a patch using bazaar) and attach it to a 
bug report requesting it to be reviewed (which is the simplest option) OR you can upload your branch to launchpad 
(this will require you to have an ssh key attached to your account on launhcpad), request a merge, and file a bug 
report or send an e-mail to the core developers to alert them to your request. If you find this confusing, please ask 
for help! :)

If you are a member of the developer team, we ask that you use the latter option. For those using the latter option, 
remember to pass the "--fixes=lp:XXXX" flag to the commit command, replacing XXXX with the bug number, to attach your 
branch to the applicable bug report (if any).

Furthermore, if you are a member of the developer team and are making big changes or working on a project, we 
encourage you to push your branch under the sapidlib-dev team (ex. bzr push bzr+sftp://<YOUR 
USERNAME>@bazaar.launchpad.net/~sapidlib-dev/sapidlib/<BRANCH NAME>)to allow other members of the developer team 
commit access.


8. How do I ensure I don't commit unwanted changes?

Sometimes you're going to make temporary changes that you don't actually want to commit or include in your patch. 
Bazaar has some nifty commands to help you review and revert changes such "bzr status", "bzr diff", and "bzr revert". 
Type "help bzr <cmd>" (replacing <cmd> with the name of the command) for detailed help.

A list of things you probably want to remove before commiting/creating a patch are:

    * Changes to etc/config.lpu (such as changing the mud name)
    * Log files (such as files under lib/log/)
    * User data files (such as files under lib/data/users/)
    * User home files/directories (files under lib/home/)
    * lib/adm/etc/groups and lib/adm/etc/access
    * etc.

Your commit/patch should only contain specific changes.

If you realize you've made a mistake after making a commit, the uncommit command will be helpful (see: bzr help 
uncommit).


9. Why are there are so many different branches?

Bazaar is a distributed version control system which means that there is no central repository people are locked 
into. This makes it easier for people to fork and go in different directions or work on a big project without being 
disruptive to others. To create a new branch, you simply use the "bzr branch" command or (even more simple) make a 
new copy of the directory containing the branch. Bazaar makes it easy to merge branches back into each other allowing 
for rapid, heavy concurrent development. Having multiple branches also allows us to have permissions, see FAQ #10.

Example: You want to work on the lockdown daemon so you create a new branch called lockdown_d which you work on 
commiting your changes. In the mean time, the mainline branch (devel) has been updated so you use the bzr merge 
command to pull in those changes. Later, when you're happy with your work, you submit your branch for review and it 
gets merged back into the mainline branch.


10. How are branch permissions managed?

Branch permissions (the ability to push/upload your changes to a specific branch on launchpad) is managed by where 
you upload your branch to. The basic format for branch URLs (for uploading) is: bzr+sftp://<YOUR USER 
NAME>@bazaar.launchpad.net/~<TEAM OR PERSON>/<PRODUCT/PROJECT>/<BRANCH NAME>

TEAM OR PERSON: This field is either your username or the name of a team you belong to. In this case, if you are a 
member of developer team it would be sapidlib-dev (sapidlib-dev-core for core developers). If this "field" is your 
username, only you will be able to upload (push) to that branch. If the field is the name of a team you belong to, 
all the members of that team will be able to upload (push) to that branch. Note: The name is prefixed with ~

PRODUCT/PROJECT: If your branch is related to sapidlib, this field should be "sapidlib". This will associate your 
branch with the project on launchpad making it easier to find. It currently does not affect permissions.

BRANCH NAME: This is the name of your branch. Please try to intelligently name your branch (it should describe the 
focus of the branch). For example, if you created a new branch to work on fixing a bug that has to do with the ftpd 
server and wish to upload it, you might name it ftpd.bug5669853 (5669853 being the bug number).

It is strongly encouraged that you upload branches under ~sapidlib-dev (if you can) so that the team can interact 
with them.

If you'd like to host your branch yourself, you can mirror it and register it with Sapidlib by visiting 
https://launchpad.net/sapidlib/+addbranch.

Note: If you ever make a mistake when uploading, you can modify it via launchpad. Please do not upload your branch 
multiple times. If you do, mark the old one(s) as abandoned.

Example upload: bzr push bzr+sftp://cody-somerville@bazaar.launchpad.net/~sapidlib-dev/sapidlib/ftpd


11. How do I get shell access to Osunta?

All members of the Sapidlib Developer Team are given shell accounts to Osunta (our developer server) via a script 
which is ran nightly. For the script to add your account, you must have a valid ssh key uploaded to your launchpad 
account. You will utilise that key and your launchpad id to authenticate.

A list of developers utilising their web space is coming soon.

Resources are limited. Please be considerate of others and do not run scripts/programs that are resource intensive.

Example ssh command: ssh cody-somerville@lpuni.org


Sapidlib Project FAQ
/home /sapidlib /Project FAQ
FAQ Index

   1. Sapidlib? TMI-III? LPuniMudlib? What is the real name of this project?
   2. Who directs the project?
   3. Can you explain the hierarchy?
   4. Why do you have a hierarchy?
   5. How do I get involved?
   6. How do I get the latest code?
   7. How do I submit my changes?
   8. How do I ensure I don't commit unwanted changes?
   9. Why are there are so many different branches?
  10. How are branch permissions managed?
  11. How do I get shell access to Osunta?

Questions & Answers
1. Sapidlib? TMI-III? LPuniMudlib? What is the real name of this project?

The mudlib has gone through a number of different name changes for a number of different reasons. Recently (Dec 
2007), the mudlib project was renamed to "Sapidlib" - the original name of the mudlib.


2. Who directs the project?

The Sapidlib mudlib project is directed by the members of the Sapidlib Core Developer Team (sapidlib-dev-core) with 
Cody Somerville being the lead developer. It is desired to get general consensus from the people actually doing the 
work.


3. Can you explain the hierarchy?

The Sapidlib project has a very simple, linear hierarchy that is used to manage permissions and to help identify 
individuals who are trusted contributors.

   1. Core Developers
   2. Developers
   3. Casual contributors

Casuaul contributors are folks who contribute here and there usually by submitting patches, filing bug reports, and 
helping other users.

Developers are contributors who have proven themselves to be trustworthy, are looking to get more involved, and have 
a history of sustained contribution. Developers have further access on launchpad (such as being able to set the 
importance of bugs and upload rights to certian bazaar branches) as well as access to other tools/infrastructure 
helpful to developing the mudlib.

Core Developers are developers who have became big movers and shakers by taking on big projects, showing a 
consistency to produce high quality code, and are looking to have a leadership role within the project to some 
degree. Core developers have even more access on launchpad (such as being able to create series, make releases, and 
have commit access to our primary maineline development branch).


4. Why do you have a hierarchy?

Our project utilises the simple hierarchy described in FAQ #3 to lower the barrier to becoming a contributor. Instead 
of it being an all or nothing system, developers can get the appropriate access they need for the level of 
contribution they are willing to give.


5. How do I get involved?

We attempt to making getting involved as easy as possible but the answer to this question entirely depends on what 
you want to get involved with. For example, if you're interested in getting involved with coding or documentation, 
simply download the latest code and start editing and/or creating new content. You'll be able to create a patch which 
you can attach to a bug report asking for a developer to review. If you have an idea for contributing some other way, 
feel free to talk to a member of the core developer team about it.


6. How do I get the latest code?

Our project makes use of a revision control system called bazaar. To find out how to install this tool, visit 
http://bazaar-vcs.org/Download. For a quick tutorial, see: 
http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html. The user guide can be found at 
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html.

Our project has different "series" which represent releases (allowing us to maintain old releases or even seperate 
work for future releases). One of these series is called "trunk" which is the current development focus and will 
become the next release. Generally, the branch attached to the trunk contains the latest code. By visiting 
http://launchpad.net/sapidlib/trunk, you can find the link to the current development branch which actually gives you 
the commands you need to type (word for word) to download it (ex. bzr branch 
http://bazaar.launchpad.net/~sapidlib-dev-core/sapidlib/devel).

The mainline development branch is also exported nightly and placed in lpuni.org/nightly/.


7. How do I submit my changes?

Our project uses a model called "Decentralized with human gatekeeper". In this workflow, each developer has their own 
branch or branches, plus read-only access to the main branch (ie. the trunk). One developer (the gatekeeper) has 
commit rights to the main branch (in our cases, core developers). When a developer wants their work merged, they ask 
the gatekeeper to merge it. The gatekeeper does code review, and merges the work into the main branch if it meets the 
necessary standards.

You can either generate a patch (type "bzr help diff" to see how to create a patch using bazaar) and attach it to a 
bug report requesting it to be reviewed (which is the simplest option) OR you can upload your branch to launchpad 
(this will require you to have an ssh key attached to your account on launhcpad), request a merge, and file a bug 
report or send an e-mail to the core developers to alert them to your request. If you find this confusing, please ask 
for help! :)

If you are a member of the developer team, we ask that you use the latter option. For those using the latter option, 
remember to pass the "--fixes=lp:XXXX" flag to the commit command, replacing XXXX with the bug number, to attach your 
branch to the applicable bug report (if any).

Furthermore, if you are a member of the developer team and are making big changes or working on a project, we 
encourage you to push your branch under the sapidlib-dev team (ex. bzr push bzr+sftp://<YOUR 
USERNAME>@bazaar.launchpad.net/~sapidlib-dev/sapidlib/<BRANCH NAME>)to allow other members of the developer team 
commit access.


8. How do I ensure I don't commit unwanted changes?

Sometimes you're going to make temporary changes that you don't actually want to commit or include in your patch. 
Bazaar has some nifty commands to help you review and revert changes such "bzr status", "bzr diff", and "bzr revert". 
Type "help bzr <cmd>" (replacing <cmd> with the name of the command) for detailed help.

A list of things you probably want to remove before commiting/creating a patch are:

    * Changes to etc/config.lpu (such as changing the mud name)
    * Log files (such as files under lib/log/)
    * User data files (such as files under lib/data/users/)
    * User home files/directories (files under lib/home/)
    * lib/adm/etc/groups and lib/adm/etc/access
    * etc.

Your commit/patch should only contain specific changes.

If you realize you've made a mistake after making a commit, the uncommit command will be helpful (see: bzr help 
uncommit).


9. Why are there are so many different branches?

Bazaar is a distributed version control system which means that there is no central repository people are locked 
into. This makes it easier for people to fork and go in different directions or work on a big project without being 
disruptive to others. To create a new branch, you simply use the "bzr branch" command or (even more simple) make a 
new copy of the directory containing the branch. Bazaar makes it easy to merge branches back into each other allowing 
for rapid, heavy concurrent development. Having multiple branches also allows us to have permissions, see FAQ #10.

Example: You want to work on the lockdown daemon so you create a new branch called lockdown_d which you work on 
commiting your changes. In the mean time, the mainline branch (devel) has been updated so you use the bzr merge 
command to pull in those changes. Later, when you're happy with your work, you submit your branch for review and it 
gets merged back into the mainline branch.


10. How are branch permissions managed?

Branch permissions (the ability to push/upload your changes to a specific branch on launchpad) is managed by where 
you upload your branch to. The basic format for branch URLs (for uploading) is: bzr+sftp://<YOUR USER 
NAME>@bazaar.launchpad.net/~<TEAM OR PERSON>/<PRODUCT/PROJECT>/<BRANCH NAME>

TEAM OR PERSON: This field is either your username or the name of a team you belong to. In this case, if you are a 
member of developer team it would be sapidlib-dev (sapidlib-dev-core for core developers). If this "field" is your 
username, only you will be able to upload (push) to that branch. If the field is the name of a team you belong to, 
all the members of that team will be able to upload (push) to that branch. Note: The name is prefixed with ~

PRODUCT/PROJECT: If your branch is related to sapidlib, this field should be "sapidlib". This will associate your 
branch with the project on launchpad making it easier to find. It currently does not affect permissions.

BRANCH NAME: This is the name of your branch. Please try to intelligently name your branch (it should describe the 
focus of the branch). For example, if you created a new branch to work on fixing a bug that has to do with the ftpd 
server and wish to upload it, you might name it ftpd.bug5669853 (5669853 being the bug number).

It is strongly encouraged that you upload branches under ~sapidlib-dev (if you can) so that the team can interact 
with them.

If you'd like to host your branch yourself, you can mirror it and register it with Sapidlib by visiting 
https://launchpad.net/sapidlib/+addbranch.

Note: If you ever make a mistake when uploading, you can modify it via launchpad. Please do not upload your branch 
multiple times. If you do, mark the old one(s) as abandoned.

Example upload: bzr push bzr+sftp://cody-somerville@bazaar.launchpad.net/~sapidlib-dev/sapidlib/ftpd


11. How do I get shell access to Osunta?

All members of the Sapidlib Developer Team are given shell accounts to Osunta (our developer server) via a script 
which is ran nightly. For the script to add your account, you must have a valid ssh key uploaded to your launchpad 
account. You will utilise that key and your launchpad id to authenticate.

A list of developers utilising their web space is coming soon.

Resources are limited. Please be considerate of others and do not run scripts/programs that are resource intensive.

Example ssh command: ssh cody-somerville@lpuni.org



