Penguin
Diff: MeetingTopics.2005-10-31
EditPageHistoryDiffInfoLikePages

Differences between current version and predecessor to the previous major change of MeetingTopics.2005-10-31.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 5 Last edited on Sunday, June 3, 2007 3:51:21 pm by CraigBox
Older page: version 3 Last edited on Friday, November 25, 2005 4:20:02 pm by MatthiasDallmeier Revert
@@ -1,23 +1,114 @@
-!! IanMcDonald presents "Contributing to Open Source Projects". 
+!! IanMcDonald presented "Contributing to Open Source Projects". 
  
 __Date:__ Monday 31 October %%% 
 __Time:__ 7:30pm[1] %%% 
 __Location:__ I.G.02 at WaikatoUniversity 
  
-In his presentation, Ian will cover
+In his presentation, Ian covered
  
-* wiki-ing  
-* !SourceForge  
-* source code management systems  
-* writing documentation  
-* use of mailing lists (including warnings about flames etc)  
-* submitting code  
+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.  
  
-It is aimed at all levels - everyone, even if they can't code, can contribute by testing, documenting etc.  
+!Use it!  
  
-Ian has returned to PhD studies at WaikatoUniversity after 15 years in the IT workforce . His research is on congestion control in networking and has contributed to many open source projects, notably including the [DCCP] protocol for Linux , which is currently being merged into the main Linux kernel
+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  
+* Working to get [DCCP] into LinuxKernel.  
+* Working with other projects such as TcpDump and ttcp  
  
 ---- 
-MeetingTopics  
+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. 
+# [|ftnt_ 1]~[[1|#ftnt_ref_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.