- This page was last modified 10:41, 6 January 2007.
- This page has been accessed 3,908 times.
- Privacy policy
- About Buni.org
- Disclaimers
Contents |
The most frequent question for those interested in contributing to open source is "where do I start?". There is no clear cut answer because there are many types of contribution. Often times sending an email offering to help receives a tepid reply, though at Buni we try very hard to break that "tradition" in open source. The tepid reply is partly because offers to contribute greatly outnumber actual contributions (even when a warm reply is received). Secondly, a lot of times folks are focused on their own contributions more than helping others (we try and focus on the human side too). You need to make sure you have some time to contribute, legal standing to contribute (for instance no binding agreement with your employer which prevents such contributions), and the ability to contribute to the project that you're offering to contribute in the manor you have offered to contribute. Meaning don't offer to help write a low level rasterizer for your favorite open source C++ game if you've never written C++ before (baby steps). We REALLY want coders, don't get us wrong, but there are easier ways to get "in" to a project.
Sadly this is an area of great need in any software product and a skill that is often lacking in open source developers. If you can write or at least generate "notes" and "instructions" for your own later review, consider starting a page on the Buni wiki. It may be a good idea to send an email to meldware-dev@buni.org to ask "where" is the best place to "put" the page. But you can easily at least start a page (and link it in somewhere later) by pasting a link in this pattern into your browser: http://www.buni.org/mediawiki/index.php?action=edit&title=MyPage replacing the title with your page's title. It may be a good idea to search the buni.org site with a search engine like Google before writing the page as you may be able to just edit an existing page. In google, type "site:buni.org Some Keywords Describing My Page".
If you offer to contribute the first thing that someone is likely to do is tell you to get the source from the repository and build it first. Its impossible to develop code on an open source project without a good understanding of how revision control works and how to create patches. Once you make it that far, the next thing you'll likely be given is a trivial bug in Bugzilla. We welcome all contributions (that are in scope for our projectts) but it is easier to familiarize yourself with a new codebase if you have some goal. It also helps you familiarize yourself with making patches if you're new. You can search Bugzilla for open bugs with a link/query like [| this].
If you have a good understanding of the software, then doing focused testing is a GREAT way to help. Following that, filling bug reports in Bugzilla (be careful to confirm and fully explain the scenario) is a great way to help. Do not file questions in bugzilla. Do that in the mail list (meldware-dev@buni.org).
Got a spare E15000 sitting in your garage? We could really use your help seeing just how well we can scale. Time in QA and testing labs is GREATLY appreciated. Write meldware-dev@buni.org or andy@buni.org (if you need some level of discretion) to discuss how you can help here!
Time on smaller hardware is also appreciated, it also helps to have other platforms to regularly run our unit tests on.
If you're testing and filing bugs or requesting new features, consider writing a unit test that demonstrates the bug. Its a good idea to talk to folks on meldware-dev@buni.org to decide on the best approach to writing the test and where to structure it in the source/build.
Frankly, we give out committership easily (access to commit changes to the Source Repository directly. It is primarily a result of you sending in enough patches to make it more expedient than applying them and demonstrating that you understand how to use CVS well. Note that unlike [| Apache], committership doesn't really give you any special voting rights or whatever. We are a karmic do-ocracy rather than a meritocracy. Without splitting hairs, decision making is informal and the greatest weight is given to the opinion of the person who is going to DO the work. Not to say we won't whine at you, but its advice. That being said, massive changes that disrupt the project need to be discussed and potentially done on a branch in the repository or you may loose karma. Wanting to "DO" something and having everyone trust you with adequate "karma" may not be the same thing. So watch your karma. Be constructive and follow through with what you say you're going to do roughly when you say you're going to do it.
This is supposed to be fun. If you're overwhelmed and stressed, relax, take some time off. Then take a deep breath and Dive Right In!
Software development is a social activity. It is also an economic activity. It has long been stated that a piece of software's architecture tends to resemble the communication pathways of the group that creates it. In any given project there tends to be a high ratio of communication vs code. This is a social activity and the people around you do matter. However, unlike other projects we don't spend a lot of time philosophizing about this, it just happens to be the case. Software development is also an economic activity. Meaning effort and resources are expended and something of value is produced. You need to figure out what reward you want, it may just be "more experience" or "looks good on the resume". It may be "I want to work for Bunisoft or a partner". You decide that part. Make your goals/expectations clear to the other developers and follow up on it "hey can I have a reference?" or "can you keep me in mind if you have an opening in the area of X and Y -- I can do X,Y,Z to make it worthwhile". Don't ask for that on the first day, but maybe say "if I create an extensive load test tool for IMAP is that worth a reference or commendation to my employer or perspective employer?" and someone may pipe up. In short, set a goal for what your reward is, decide how much you're willing to expend, communicate it, execute it, and follow up.
Buni's community is heavily do-ocratic. This is not to say that we don't have opinions, but generally its thought that the person with the most forward energy will likely accomplish the best solution or someone else will come in behind them. We don't usually have any serious arguments (except for the one about vi being the ultimate development environment, that is absolutely true and anyone who disagrees is obviously cracked in the head) except for when something YOUR doing is getting in MY WAY (like breaking the build).
A base familiarity with CVS is required for submitting patches to Buni. There are many tools for working with CVS. We'll describe use of the command line tools.
On Windows, the easiest way to get CVS and the tools you need for using CVS, submitting patches from the command line is to install Cygwin. Cygwin provides common GNU tools as well as a BASH shell (similar to that used on Linux). Install Cygwin with the setup.exe. Following this install the cvs, ssh and "patch" tools as well as any of their requirements. From there on launch a cygwin session and for the most part any Linux command line instructions should generally work (the mappings to Windows drives like /cygdrive/c are a little different).
CVS, patch and ssh are all commonly available via modern Linux distributions package manager. The only things you have to figure out is "what is my package manager called" and "what is the package called". Luckily to the latter question are probably cvs, patch and ssh. Install those three tools. Its also possible to get source distributions and roll your own builds, but if you are the type to do that then you're probably not going to need this guide (welcome uber-geek!). Note that many linux variants have graphical tools for their package managers.
Common Package Systems for Linux variants:
To check out the source, find yourself a free directory and follow the instructions here. Following this move into the "meldware" module subdirectory.
Assuming you've changed something and wish to create a patch file, make sure you're in the "meldware" directory (aka "working copy") and type: "cvs diff -u > mypatch.txt" (please name the patch something more meaningful). This will create a patch file with deltas of every file you have changed in a easily applied format.
If you have added files then please either:
OR
If a luni attempts to commit the patch and it fails for various formatting or other issues then he/she/it may comment on the patch. Generally bugzilla will send you an email about this. However, please follow up on your patches as they are applied and make it into a build to ensure they indeed make it!
Please read out notes on Coding Style
We're fairly liberal with giving write access to our repository. Mainly we want to make sure you're going to be around long enough to justify the time spent adding you to the permissions, you can work reasonably well with others (let's face it software developers aren't the most personable of people -- though we aim to break that cycle) and won't screw the repository up. The bar to entry isn't too high it is just:
Basically after the first few patches that take us less time to apply than it took you to code we let you in if your code isn't too crappy :-).
Buni.org projects are not really "meritocracies". In a meritocracy someone can build up a lot of karma and then they gain a vote. Meritocracy is more subject to abuse. Once you build merit you can really derail progress.
Buni.org projects are limited "do-ocracies". At Buni, ideas are freely discussed but if you whine about something you're basically volunteering to fix it. The opinions of those NOT doing the work should be listened to, but are merely advice.
That being said there is a karmic component to Buni. If in your first post you promise a RealBigThing change that everyone likes, you'll still probably be at least advised to "wait". Big changes are disruptive. Risking that you'll burn out mid RealBigThing may be too much for the mood of those you are working with. So they may object. This form of "earn enough stripes" to make the commitment is the meritocratic element of Buni do-ocracy.
If this is fuzzy and confusing, don't think too hard about it. We don't.