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 <i...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
