acmeattic-devel team mailing list archive

[Aditya Manthramurthy <aditya.mmy@xxxxxxxxx>]

-----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 <surenspost@xxxxxxxxx>
To: Aditya Manthramurthy <aditya.mmy@xxxxxxxxx>

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-----