cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject [DISCUSS] Checking in code that will break others' environments
Date Wed, 05 Mar 2014 20:19:01 GMT
Hi,

I encountered a bit of a problem this morning and thought I would bring it
up for discussion.

If we already have a policy around this, please let me know.

So, I fetched the latest and rebased my local 4.4 development branch on top
of master. This all went just fine.

When I rebuilt and re-started the CS Management Server, I soon realized I
could no longer log in from the GUI.

As it turns out, the DB schema had been updated and so my database was out
of date. The code was querying for fields that didn't exist in my DB.

As far as I know, the easiest way to get around this is to destroy my
current cloud, run the script to re-build my database, then re-create my
cloud, which is somewhat time consuming.

Do we have a process in place currently in which we ask those who make such
changes to send out a notification e-mail to dev@ to give people a heads up
that updating will lead to such issues? On previous projects, we would send
out an e-mail and then people could be aware to only update if they were
prepared for such re-work.

To be clear here, I'm not meaning to pick on anyone in particular...this
has happened several times over the course of my CloudStack development and
I expect that I, too, have checked in such code (without sending out a
relevant e-mail) that lead people to have to perform such a complete
re-build action un-expectedly.

What do people think about this? Maybe we should just add an e-mail tag or
something and point people to the relevant commit?

Thanks!

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message