cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [DISCUSS] Checking in code that will break others' environments
Date Wed, 05 Mar 2014 20:38:36 GMT
Yeah, in this case, I'm not referring to erroneous code that breaks a
person's environment (since hopefully the person wouldn't have knowingly
checked in such code), but rather, say, DB-type changes that improve the
system, but break current setups.

Just a heads-up e-mail with some easily identifiable tag.

Can anyone think of a good tag for this? It's not always DB related, so we
might want the tag to be more general.


On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy <ian@ianduffy.ie> wrote:

> +1 to this.
>
> Having the build suddenly break due to a git pull has been very annoying!
> I usually end up searching through the commit log and doing a resets
> until I find a commit where it works. Then waiting awhile until I do a
> git pull again and hoping the code was fixed.
>
> On 5 March 2014 20:19, Mike Tutkowski <mike.tutkowski@solidfire.com>
> wrote:
> > 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)*
>



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