Penguin
Blame: MeetingTopics.2005-10-31
EditPageHistoryDiffInfoLikePages
Annotated edit history of MeetingTopics.2005-10-31 version 5, including all changes. View license author blame.
Rev Author # Line
4 IanMcDonald 1 !! IanMcDonald presented "Contributing to Open Source Projects".
1 CraigBox 2
3 __Date:__ Monday 31 October %%%
4 __Time:__ 7:30pm[1] %%%
3 MatthiasDallmeier 5 __Location:__ I.G.02 at WaikatoUniversity
1 CraigBox 6
4 IanMcDonald 7 In his presentation, Ian covered:
1 CraigBox 8
4 IanMcDonald 9 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.
1 CraigBox 10
4 IanMcDonald 11 !Use it!
1 CraigBox 12
4 IanMcDonald 13 You using open source software anywhere you can helps. You end up getting others interested, see what problems there are and help resolve them.
14
15 in particular if you are using a proprietary program see what else you can find instead.
16
17 !Wiki-ing
18
19 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.
20
21 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.
22
23 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.
24
25 Review the changes going on at RecentEdits
26
27 !Source Code Management (SCM) systems
28
29 [CVS] – traditional. Concept of branches of code so that bug fixes, changes can be supplied to multiple branches.
30
31 SubVersion – aimed as replacement for [CVS] and in particular to help with back porting of changes and moving files around.
32
33 [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)
34 * every patch is an object
35 * version is defined by the order of objects
36 * git-bisect – divide and conquer
37 * cogito – traditional patch management wrapper
38 * gitk - graphical patch viewing
39
40 !Code repositories:
41
42 * 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.
43
44 * WLUG. For example WLUG hosted bug tracking and info about [DCCP] for the LinuxKernel until [OSDL] ([LinusTorvalds]' employer) put up a Wiki.
45
46 !Writing documentation:
47
48 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.
49
50 !Use of mailing lists
51
5 CraigBox 52 * Always try and search the mailing list archives before you ask your question as it may have been asked and answered already.
53 * If you post something be prepared to explain it.
54 * This is one of the key areas developers “hang out” (other one being IRC).
4 IanMcDonald 55
56 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
57
58 !Flaming
59
60 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.
61
62 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
63
64 !Submitting code
65
66 Please submit code upstream – a lot of people fix a problem, add a feature and then don't share it with the world.
67
68 It is very unusual for code to be accepted first time. Don't be put off but fix what people say.
69
70 !Bug reporting
71
72 Vendors often ship modified code and tweak it, rather than use upstream version.
73
74 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.
75
76 If not confident then go to your LinuxDistribution site and submit on their bug system.
77
78 !Bug submission
79
80 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.
81
82 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.
83 * Version of program
84 * Can the problem be reproduced?
85 * All the steps to cause the problem
86 * Logs from the program
87 * Any error messages
88 * Configuration files
89 * Usually the program authors will give a list of what info to supply when reporting bugs. Read this and do it!
90
91 !Bug testing
92
93 Most projects need people to test bugs as often people don't submit enough information.
94
95 Need testing for fixes to verify that problem is really fixed.
96
97 !Testing
98
99 Download latest betas and test them. Often there are not many people testing new software which is why there are problems with new releases.
100
101 !Pick something new and implement it
102
103 Every project started somewhere. E.g. BruceKingsbury with his [KiaoraCD].
104
105 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.
106
107 !Personal experience
108 * Working to get [DCCP] into LinuxKernel.
109 * Working with other projects such as TcpDump and ttcp
1 CraigBox 110
111 ----
5 CraigBox 112 OldMeetingTopics
1 CraigBox 113
5 CraigBox 114 #[|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.