From my personal standpoint, I just really care that the code is clean and readable. I understand that the term "readable" is subjective, but someone shouldn't have to sit there for an hour trying to figure out what a single function is doing :)
Another thing that I always try to do before a commit to SVN is be sure that the code at least compiles, especially if its under /trunk. Whether it works or not is another story, but someone should be able to take it out of SVN and build it without errors. This is a bit different when it comes to Python where some errors (i.e., some undefined variables) aren't flagged until the interpreter hits that line of code, but the interpreter should still be able to load the files and start running them. If there are massive changes to something (re-architecting, etc) it would probably be easier to do the development in a branch instead of the trunk. Then it won't impact those people building from SVN, and you can also have a bunch of smaller commits during the development. To keep SVN clean with this approach, things should be merged back in to /trunk when done, and the branch should be deleted. Having code in a branch compile/run all of the time probably isn't crucial. Of course, this are just suggestions to hopefully avoid headaches down the line. Like David I will stay out of the way and if something breaks, it breaks. :) -- Richard Alimi Department of Computer Science Yale University On Wednesday 16 January 2008, David Eriksson wrote: > > Hi, > > > > I'm about to do some commits, but it got me thinking - I will most > > likely not get a reply till later (which is fine) but what are the > > unwritten rules you guys follow (if any)? eg. testing, QA, etc. > > > > I was checking out how shiny my name looked here > > http://sourceforge.net/project/memberlist.php?group_id=30550 and I > > thought "wow, 30 devs". Then I thought "are they all active?". And > > finally I thought why not take a leaf out of Gentoo's book and make some > > notes for developers. Not necessarily "I want to be a dev", but more > > like "I am a dev, and I forgot what so-and-so said about directory > > structure" or something. > > > > If anyone thinks this would be useful, reply by email and I'll happily > > throw your notes together on the wiki. > > For a long time (pre-WM5), SynCE was pretty much a two-man shop with > Volker and me, while others made guest appearances of various magnitude. > We could either keep the membership list as "credits", or we could clean > it. (I'm still a member of the ScummVM project but my last commit was 4-5 > years ago... :-) > > By the way, I'm very, VERY, happy that SynCE development regained velocity > with the WM5 support! > > Anyway, I have never tried to impose any rules on the development because > I was happy for every little contribution I could get! That's why there is > inconsistent spaces/tabs in source code, different licenses, etc. I did it > my way (two spaces for tab, MIT license, etc) while others did things > their way (GPL license, etc). > > I'd say that this is a maturity thing for a project and it could be that > SynCE has reached a point where some structure would be beneficial. > However, I will try to not interfere in this more than with this mail... > > :-) > > Cheers, > > David > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > SynCE-Devel mailing list > SynCE-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/synce-devel
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
