-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Suren, you should make sure to sent to the mailing list instead of to me! - -------- Original Message -------- Subject: Re: [Acmeattic-devel] Software engineering Date: Fri, 16 Jul 2010 11:56:15 +0530 From: suren <[email protected]> To: Aditya Manthramurthy <[email protected]> Hi, >> Given that this is the first time I am involving myself in a serious >> project, here are some questions I had. It also feels better to put it down >> in a doc. >> >> - *Coding style:* Do you use a known standard for formatting code? Could >> you pass on a link to the same. I found these: >> Google<http://google-styleguide.googlecode.com/svn/trunk/pyguide.html>, >> PEP8 <http://www.python.org/dev/peps/pep-0008/> > > I think the best is to use PEP 8 [1] for coding style conventions and > PEP 257 [2] for docstrings conventions. The google standard seems to be > a superset of PEP 8, and has very detailed instructions. It would be a > pain to follow all of them carefully. PEP 8 is good enough for the > standard python libraries, and so should be good enough for us. > > [1]: http://www.python.org/dev/peps/pep-0008/ > [2]: http://www.python.org/dev/peps/pep-0257/ > The reason I suggested Google was that it looked to cover almost all our points. I guess I can get a vimrc that will automatically take care of most stuff there. > >> - *Code reviews:* I advocate the following: >> - Any code *has* to be reviewed by someone else before Commit. (OFC >> all of us are committers). Maybe two reviews in the early stages? >> - Coding style is enforced at this stage >> - Techniques used are reviewed > > I think a single review by a member of the acmeattic-devel is enough. > Trivial bugs should be caught here. When bugs arise, the people who > implemented/reviewed the feature, have a priority to fix that bug, > failing which anyone else can fix it. > In the pairing up model I suggested, Does it make sense the people in pairs review each others' code ? > To compile python files, without executing them, there is a command > "py_compilefiles" which tries to form the byte-compiled versions of the > files (.pyc). This will do syntax checking, and we can use it. > This is nice. But this should be a pre-commit hook. I am assuming bazaar client has pre-commit hook model. Almost all version control systems I know have that. Not sure about Bazaar. >> - *Documentation:* Document your Classes, methods and variables during >> implementation. A little extra documentation never hurt anyone. >> - The Wiki usually captures the high level documentation and does not >> contain implementation details >> - Some of us might think of magic hacks that work - lets enlighten >> others how that works! > > See PEP 257 about docstrings. We should consider it a priority to write > docstrings and keep them updated the code changes. For software > documentation, we should consider using sphinx [3]. It is the technology > used to generated sexy looking documentation like at http://docs.python.org > > [3]: http://sphinx.pocoo.org/ > >> http://www.stack.nl/~dimitri/doxygen/ - this is also popular. But does not give like pydoc though. >> Is there anything that I've missed? >> > > How should we organise development itself? > > My answer is to organise a series on lp. Say the 0 series - this > represents releases of the s/w that have version numbers like 0.1, 0.2, > etc. > > Development happens in a pre-planned way. We target bugs/blueprints to > the next minor version of the software (say 0.1 is stubs, we then map > the blueprints/bugs for getting to 0.2), and developers can pick up one > of these targets (bugs/blueprints) and develop them on their own. Review > happens by another member of the devel team, and then committed to trunk. > > When we have enough new features to create a stable release, before we > create it, we do lots of testing, creating alpha, beta releases, and > then we create the stable release and publish packages for it. When a > new phase of development starts, like say we decide to rewrite the > encryption system (for whatever reason), we can start a new series like > series 1.x, 2.x, etc. How does this sound? > > If this sounds good, over this weekend (as PK and me are planning to > meet), PK and me will write simple stubs to start of the coding. The > stubs will contain names for classes or any such thing. It is just > planned to write simple command parsing code, etc, which are necessary > even in the earliest version of the s/w. We will call this version 0.1. > Of course, it can be mercilessly edited by others who are working on > specific featurs later on :-) > > In the meanwhile, it will be good to decide what features to include in > stable release 1! There is feature release schedule at [4]. We should > edit that to get an overview of features in future releases. Once that > is ready, we can write specific blueprints for minor releases, and begin > coding intensively! > This looks okay to me :) - -- regards Suren http://twitter.com/suren http://flickr.com/suren_m -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJMQBszAAoJEJp+wO5X65iGQ8IP/2puqjsbuQSIb5yCnhQ1/HCM ICIcfHAirjke46/lIzO13DRm+sC3he75xMvUP9+40QV+G5O4sK+yhVMYFXtTHXLL DrrHWnunMqb4Rb8YSOUemsz+bM1sOo2bBa2/+cApdDHlhIeK3EpK35salmMPFcP+ b2b0EAFDRadLpbVev4RwZxq3oD10hyvOjeZOep+izl0aTIrgN2aIO+Q8AK5tpNZl 0X/JXm8QMpxxyX8pj585LQIEnzlKtA5fH43bE8Ttr8p40Dr2C5uuj9IYePJVDbKJ Q0ljFl8J6/SrOVvVDvhsEnsVJ5BA/FAikzfjYnKubTD6JvyTSoLr8gPOSD9atWQu hg43kfqo0tSNZM9AFegyN+OSc9Knh9mgd9GeyDCB5I4WZzEHkLoLPtDIfUqJQeX7 tpVpffpbdxBHYCrI3NBN4SXxSgEB8EDCFVgvyYMbTKsvTCXNbB8AOV0ojlJEM76I jEB9n5qAjOVeA4nZN51+bldqi0VQfY+GRIdoZwLexXzZAHupeDPcnxTA6eb7eVK8 wdHRAaD5GNXyjOWCk764yw85cToKL2uhetTfVDRLCB8hf2ODGof6kiPQl50kT4hP NvizTkuuXSPVWGU6ekUVkOY0+Q198DORcdrAw7dS8Sdv1qXDP7CgO/MZUkOSP0tP Qd5eUpoQJQ56NBabEkSf =k70I -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~acmeattic-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~acmeattic-devel More help : https://help.launchpad.net/ListHelp
