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.
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.
The Sapidlib project has a very simple, linear hierarchy that is used to manage permissions and to help identify individuals who are trusted contributors.
Casual 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).
Our project utilizes 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.
We attempt to make 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.
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 will be marked as the current development focus and will become the next release. Generally, the branch attached to this series contains the latest code and is often called the “trunk” or “head revision”. By visiting http://launchpad.net/sapidlib/ you can find the link to the series attached 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). You can always download the current development focus by typing:
bzr branch http://bazaar.launchpad.net/sapidlib
The mainline development branch is also exported nightly and placed in http://lpuni.org/nightly/.
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 launchpad), 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 to allow other members of the developer team commit access.
ex. bzr push bzr+sftp://<YOUR USERNAME>@bazaar.launchpad.net/~sapidlib-dev/sapidlib/<BRANCH NAME>
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:
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).
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.
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
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 utilize that key and your launchpad id to authenticate with Osunta at lpuni.org.
A list of developers utilizing 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
To get an @lpuni.org e-mail address (which gives you access to a number of other google powered applications), you can request it by e-mailing support@lpuni.org. To be eligible for an @lpuni.org account, you must be a member of the Sapidlib Developer Team or a recognized casual contributor.
Note: It is possible to configure your @lpuni.org address to forward to your normal e-mail account.
There are plans to make this automated in the future.