Dev Guidelines

[Martyn Taylor]

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

[Jason Guiditta]

On Mon, 2010-11-15 at 06:54 -0500, 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

Martyn, this is a good idea.  I hope everyone feels comfortable enough
to ask questions, both here and in irc.  We are an open group, so
questions/debate are always welcome.  Maybe once we have assembled said
list of questions on the wiki, and built out decent answers, we can
promote it to regular site content to make it more 'official'.

FWIW, I completely agree that refactors should be done in a separate
patch, trying to squeeze them into a bugfix not only is harder to read
for changes, but increases the chances of inadvertently breaking
something else in the process.

AFA the testing and error-handling bits above, are those questions, or a
promise to write something up?  If the former, what are the questions?

-j

[Martyn Taylor]

Hi Jay,

Could capture any discussion over the mailing list, even if its just the conclusion of an IRC discussion, this way everyone gets to see :)

Regarding Testing,

Ladislav sent a mail voicing some concerns regarding testing.  I think we likely need some discussion on this.  I can talk to Ladislav when he returns from PTO, and we could maybe come up with an initial set of guidelines for consideration, mainly to address what we should be testing for? test cases?  e.g. Testing for failures, extreme values, standard values, etc...  Maybe what to do when a test is beyond the realms of spec and cucumber.  Or anything else anyone thinks.

Error Handling.

Again discussion will likely bring out more detail here, and there maybe standard RoR practices, but a few things off the top of my head that I am unsure of:

- When to throw/catch an exception (In the past I have always passed exceptions up the chain (never just burried it) to where an appropriate action is taken, i.e. message to user, logging, recovery etc...)
  - When to add an error to an object.errors and when to just display a flash message

Thanks

Martyn

----- Original Message -----
From: "Jason Guiditta" 
To: "Martyn Taylor" 
Cc: "deltacloud-devel" 
Sent: Monday, November 15, 2010 8:40:28 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [deltacloud-devel] Dev Guidelines

On Mon, 2010-11-15 at 06:54 -0500, 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

Martyn, this is a good idea.  I hope everyone feels comfortable enough
to ask questions, both here and in irc.  We are an open group, so
questions/debate are always welcome.  Maybe once we have assembled said
list of questions on the wiki, and built out decent answers, we can
promote it to regular site content to make it more 'official'.

FWIW, I completely agree that refactors should be done in a separate
patch, trying to squeeze them into a bugfix not only is harder to read
for changes, but increases the chances of inadvertently breaking
something else in the process.

AFA the testing and error-handling bits above, are those questions, or a
promise to write something up?  If the former, what are the questions?

-j

[Mo Morsi]

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
> [e-mail]
> 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