acmeattic-devel team mailing list archive

[suren <surenspost@xxxxxxxxx>]

Damn ! Sorry about that !

On Fri, Jul 16, 2010 at 2:11 PM, Aditya Manthramurthy
<aditya.mmy@xxxxxxxxx> wrote:
> -----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-----
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel
> More help   : https://help.launchpad.net/ListHelp
>



-- 
regards
Surendran
Yahoo! SDC.

http://twitter.com/suren
http://flickr.com/suren_m