[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
An interesting and almost certainly very useful reply which i will read over properly later when i have more time :) Very quickly, the point about mame was probably a bad example! The mamedev's are a fairly extreme example of how devs can keep things to themselves. I'm not aware of any public documentation on how any of the now massive program works (exe file in the region of 25mb before compression) and it is largely macro based. All the driver files make little sense from a programming language point of view, hence the "wouldn't know where to start" comment! The problem of not getting credit for something comes from the fact that (understandably) only certain people have access to the ftp. Consequently i put a couple of new things in, passed the additions to the dev that i know who then submitted them and the work gets credited to them! Me, no, i'm not bitter :o) To be fair, there are probably hundreds of people that contribute to that project and it would be impossible to credit everyone - the code with probably grow massively for starters! Martin. On Monday 21 March 2005 14:24, Neil Williams wrote:
On Monday 21 March 2005 12:40 pm, Martin White wrote:Yep, i'd love to, but read on...With your members area password, you might like to put this in the Members Register - you can read other people's info as well.So, what do i do? Mainly image conversion. Taking raw input data streams,imagemagick type stuff?deblocking stuff, making sense of it and then more times than not converting some format or other to PDF.I've just finished an upgrade for the GnuCash documentation that uses DocBook XSL so that it can be used with DocBook SGML to render PDF's. The XSL tool required Java and I never use it. I don't do graphics, I prefer text.Now then, therein lies the problem. I'd love to get on board and contribute some work to linux. Always have wanted to.General tips here: http://code.neil.williamsleesmill.me.uk/startqof.html http://www.dcglug.org.uk/wiki/?id=DevelIntro (feel free to add to that Wiki one). Get yourself a SourceForge Id: http://sourceforge.net/ (You'll find me at: https://sourceforge.net/users/codehelpgpg ) It helps to advertise your skills, helps other projects find you and makes it easier for them to take you onto the team. Search SourceForge and Freshmeat (http://freshmeat.net/) for the kinds of programs that you already use and which are within your areas of interest.A few years back i was at a linux show and saw a very good book on linux coding and bought it. Trouble is, i didn't have the patience to sit there and wade through all the chapters on shell programming and regular expressions before i got to what i thought i wanted to know.So don't lump in with an entire new project, join an existing project and help out with what you already know. You'll pick up other bits as you go. If you try to do everything yourself, you'll need to learn a whole host of things that you may not want to know. Let others deal with those, concentrate on what you do well by finding a niche within a larger project. However, shell programming and regular expressions are very very common and you should at least know the basics. http://www.dcglug.org.uk/wiki/?id=ShellUsageAs any programmer will know, just because you can program, doesn't mean you can (if you know what i mean). I don't know anything about how KDE works for instance.Neither do I - I do all middleware stuff, libraries and console utilities. I try not to do much GUI stuff although I've had to do a little bit with Gtk for GnuCash. http://code.neil.williamsleesmill.me.uk/Likewise enlightenment (writing this from e17 just for giggles right now). Sadly i also have very little experience of coding GUI's.No problem - pick your area and stay within your skill base. Developing free software is all about merit and respect. You get respect when your code merits it. :-) Seriously, nobody wants you to write code that is outside your particular area - that just leads to bad code. You know what you are good at coding, you know what you would be bad at coding. You know what kinds of program and what kinds of functionality interest you - that is essential because there is no-one else to motivate you to continue the work! If you aren't interested in the part of the program / API that you've taken on, you'll produce bad code.The problem comes from the fact that i find all the developers on big existing projects know exactly where they're going and what they're doingYou'll benefit from that, projects do need a strong lead. Just remember that everyone else is as busy if not busier than you. We've all got full time work, we all have other things in life, other projects in code. Individually, development can take a long time when done in your free time. Overall, because the entry barriers are so low and there are so many developers offering a few hours, development is extremely rapid and actually produces very good code too. Don't expect to get commit access to CVS for some time - most projects will have their own system for submitting patches and their own preference for the patch format. Most will involve submitting the patch to a devel mailing list so that developers with more experience of that program can make sure it will do what is needed.and if someone new comes along they're expected to miraculously know (or be able to learn just through looking at source code) how all the APIs work.Don't rush things. Take time to learn the codebase first - see my own site for my mistakes in getting involved in a large project: http://code.neil.williamsleesmill.me.uk/palm.html#BEGINNING Look for source code documentation, join the mailing list and lurk for a while. Get used to the program, use the program, find out what YOU can provide and then raise it as a solution, not a problem. The other developers are busy as well, they don't want to have a general waffle about what you can do, they need a concise and usable plan of what you want to do. If they do criticise, take it positively and see their side - your code may not fit with the overall direction of the project at that time. Don't be surprised if you don't write a line of useful code for three months or more - AFTER joining a project. I didn't. I've been working on GnuCash for over a year and it took me almost 6 months to get to a point where I had a patch that could even begin to be worth sending. Once you've invested that amount of time in a project, a few things happen: 1. You become entwined with the project and that commitment feeds your motivation - always vital in free software. 2. You get to know the other developers and build a tight-knit group despite being spread across the world. 3. The other developers get to know you and become able to help you much more easily. 4. You start to affect the project by being constructive, patient and diplomatic. GnuCash had a system for documenting the source code but the hosted site wasn't regularly updated and after seeing my problems, it was decided to update the docs from CVS every day. That made life easier for everyone. Another REALLY good tip: Don't think of contributing only as code. Developers *really* appreciate those users who help out on the project mailing lists. Use the program, answer queries from other new users, learn from the responses. THEN, when you've got some credit with the other developers for taking queries off their backs for a while, you'll get more help with your queries on understanding the source code.And that's unlikely to happen any time soon, so it kindof stifles my will to contribute.You need patience in this game. A lot of effort and time goes into learning the project as it is, before you can have any constructive ideas about where it should go.Maybe somewhere like DCLUG is the way to go since in theory there may be someone doing some projects locally with the time to explain how the APIs work and the code interacts and where they want to go with it etc, etc...Explaining the API's is best done with static documentation because you'll be referring to it endlessly.Hopefully i didn't make that sound too harsh, but i know what i mean :)I do too, I know exactly how hard it is joining a running project. I made mistakes, I want to avoid seeing others do the same.As an example, I have contributed i think two new games to mame drivers (althugh i ended up not being credited - long story),LEARN that lesson well. Understand the licence and copyright issues NOW, not when you've contributed code. There is no more important lesson - READ the GNU GPL, read the FAQ, take the quiz! Take the quiz again until you get a pass! Use the functions in your IDE / editor to create automatic copyright and licence notices. The first thing you put in ANY new file should be the copyright and licence. Before you type a line of code, get this done. Every single time. I don't care if it's a two line header file: make it a 70 line header file with two lines of code. Put the copyright and licence in!but i still to this day have absolutely no grasp whatsoever on how mame (or indeed xmame) works!! I've no idea how ANY newcomer would get to learn how that thing hangs together!!1. Join the user mailing list. 2. Join the devel mailing list. 3. Find the API documentation (Google and then ask). e.g. I found this first search: http://jausoft.com/Files/GLMame/xmame-doc.html
-- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html