On 11/15/2010 06:54 AM, Martyn Taylor wrote:
After to speaking to some of the guys on the dev team it seems some people have differences of opinion with regards to some of the ways that things are done or are maybe unsure on the best way to do something.
I suggest we write some basic guidelines for any topics that people are unsure of, or if they're seeing things that they feel should be done differently.
I think a good start would be to get any suggestions from people who feel that things should be done differently and a list of things people are unsure of. Then we could maybe collate all the stuff together and stick it in the wiki - if its a standard practice or common knowledge we could maybe add a link to a web page that explains.
Some things that we've already discussed include:
Testing: lmartinc
Error Handling: mtaylor When to use errors, throw/catch exceptions
Patch Submissions: mtaylor I feel that all refactoring should be added in separate patches, rather than including this in any bug fixes or tasks. This way we can see exactly what the changes are wft particular bugs etc...
Thanks guys
Martyn _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
Hey Martyn, thanks for getting this discussion going.
Just a couple small notes, regarding refactoring in patch submissions, I feel the same can be said about whitespace changes, with one or two its fine, but if ideally if there are alot those would be lumped together into their own separate patches.
Also re general dev guidelines we also need to make sure we integrate external components carefully and only when they are ready. Its way to easy to find a cool rubygem that does what we need and integrate it in hastily without the proper procedure.
All in all, I've been slowly compiling this "development considerations list" to post to my blog eventually, some of which would be good to standardize when working on deltacloud
* primary code interface (library, command line, daemon, sockets, web server, qmf/qpid, rpc, etc) * main functionality at hand / business reqs * operating resources constraints * edge case handling, argument / parameter checking * errors / exceptions (catching them and raising custom ones of our own) * logging * concurrency and performance * internationalization / languages / encodings * security / encryption / access control * api versions and compatibilities, naming conventions * deployment methods and software / hardware * dependencies / interacting with other components * licensing, ownership * maintenance, updates, release cycles * program termination / rebooting / resuming workloads
Programming is fun isn't it! ;-)
-Mo