Penguin

IanMcDonald presented "Contributing to Open Source Projects".

Date: Monday 31 October
Time: 7:30pm1?
Location: I.G.02 at WaikatoUniversity

In his presentation, Ian covered:

Many people think that if they are not writing Linux or OpenOffice then they can't contribute to the open source community. That is not so although you might surprise yourself and end up doing that anyway as I did! I will talk to you about what anybody can do and over time you will find your skills increase.

Use it!

You using open source software anywhere you can helps. You end up getting others interested, see what problems there are and help resolve them.

in particular if you are using a proprietary program see what else you can find instead.

Wiki-ing

WLUG Wiki is one of the best in the world (http://wlug.org.nz). I don't say this lightly – we end up getting users all around the world using the Wiki and we should be rightly proud of it.

I would suggest when something doesn't work in Linux look on the WLUG wiki, see if the solution is there. If not then research or e-mail WlugMailingList. Once done add to the WLUG Wiki.

Please don't be scared to make a change to a page. I get a few e-mails saying – can you change this page as I have more info. Be brave and do it yourself! If you get it wrong then somebody will fix it. If your spelling or grammar is bad don't worry about that either as somebody will fix it too.

Review the changes going on at RecentEdits

Source Code Management (SCM) systems

CVS – traditional. Concept of branches of code so that bug fixes, changes can be supplied to multiple branches.

SubVersion – aimed as replacement for CVS and in particular to help with back porting of changes and moving files around.

Git – Written by LinusTorvalds for the KernelDevelopment when problems arose from using BitKeeper (talked about the problem of using proprietary license for open source development)

  • every patch is an object
  • version is defined by the order of objects
  • git-bisect – divide and conquer
  • cogito – traditional patch management wrapper
  • gitk - graphical patch viewing

Code repositories:

  • http://sourceforge.net is probably the biggest general purpose open source code repository and provides free access to bug tracking, source code management, forums etc.
  • WLUG. For example WLUG hosted bug tracking and info about DCCP for the LinuxKernel until OSDL (LinusTorvalds' employer) put up a Wiki.

Writing documentation:

This is one of the weakest areas in open source. Once you have used a program for a while see how you can improve the documentation. If you know another language that can be even more useful as often there is not much help besides English.

Use of mailing lists

  • Always try and search the mailing list archives before you ask your question as it may have been asked and answered already.
  • If you post something be prepared to explain it.
  • This is one of the key areas developers “hang out” (other one being IRC).

Open source is about the best ideas not the importance of the person. Don't back down because somebody important says it. For example I've found problems with Intel's code and LinusTorvalds' code

Flaming

At some point in time somebody will “flame” you. This means somebody attacks you and sometimes it can be personal. It can be quite vicious. Try not to get upset – just reply or ignore it.

If you flame then that's fine but you've got to be just as prepared to eat humble pie when you get it wrong as you will

Submitting code

Please submit code upstream – a lot of people fix a problem, add a feature and then don't share it with the world.

It is very unusual for code to be accepted first time. Don't be put off but fix what people say.

Bug reporting

Vendors often ship modified code and tweak it, rather than use upstream version.

If confident download code from source, compile and see if problem is still there. Try and get the version that is their latest development version as invariably the answer will be “upgrade to the latest version” if you are using an old version.

If not confident then go to your LinuxDistribution site and submit on their bug system.

Bug submission

Look for the bug already being reported on their bug system or mailing list to avoid unnecessary duplicates. You might however be able to add additional information.

Always add as much information as possible. I've never seen anybody say you gave too much information but plenty of requests for more information.

  • Version of program
  • Can the problem be reproduced?
  • All the steps to cause the problem
  • Logs from the program
  • Any error messages
  • Configuration files
  • Usually the program authors will give a list of what info to supply when reporting bugs. Read this and do it!

Bug testing

Most projects need people to test bugs as often people don't submit enough information.

Need testing for fixes to verify that problem is really fixed.

Testing

Download latest betas and test them. Often there are not many people testing new software which is why there are problems with new releases.

Pick something new and implement it

Every project started somewhere. E.g. BruceKingsbury with his KiaoraCD.

However don't reinvent the wheel. It might be better to reinvigorate a near-dead project or help add new features to an existing project.

Personal experience


OldMeetingTopics

[1] As previously discussed at the AGM, all meetings from now on will be held at 7:30pm, as the reasons for holding them earlier in winter no longer apply.

lib/main.php:944: Notice: PageInfo: Cannot find action page

lib/main.php:839: Notice: PageInfo: Unknown action