From: John P. <jwp...@gm...> - 2014-05-09 15:26:09
|
On Fri, May 9, 2014 at 9:08 AM, Michael Povolotskyi <mpo...@pu...>wrote: > When the official release with the patch is going to happen? > Hard to say, we aren't on a very regular release schedule. And this wasn't a regression per se, so I don't think it's worth rushing an official point release out the door. (I also may have broken some of the less-used compiler configurations which I don't test but I think Roy and Ben's buildbots do.) Although we probably should start the discussion since the last one was almost 3 months ago. -- John |
From: Roy S. <roy...@ic...> - 2014-05-09 20:23:28
|
On Fri, 9 May 2014, Michael Povolotskyi wrote: > On 05/09/2014 11:25 AM, John Peterson wrote: > >> On Fri, May 9, 2014 at 9:08 AM, Michael Povolotskyi >> <mpo...@pu... <mailto:mpo...@pu...>> wrote: >> >> When the official release with the patch is going to happen? >> >> >> Hard to say, we aren't on a very regular release schedule. >> >> And this wasn't a regression per se, so I don't think it's worth >> rushing an official point release out the door. (I also may have >> broken some of the less-used compiler configurations which I don't >> test but I think Roy and Ben's buildbots do.) >> >> Although we probably should start the discussion since the last one >> was almost 3 months ago. > > This issue was important for us because we got conflicts between Libmesh > symbols such as DenseMatrix and our DenseMatrix class. > We simply could not compile the code. > > Before the next release we will have to carry the patch with us and > distribute it to our customers, which gives them a bad impression. > So, if the new release comes soon, we'll be very happy. It's too soon and there's too much cleanup required ATM to get out a new "real" release right away, but we ought to backport and do a bugfix release for a regression this big. I'm swamped right now, but I'll try to get an 0.9.3.1 out next week. Any other fixes worth backporting while I'm at it? --- Roy |
From: John P. <jwp...@gm...> - 2014-05-09 21:14:47
|
On Fri, May 9, 2014 at 2:23 PM, Roy Stogner <roy...@ic...>wrote: bugfix release for a regression this big. I'm swamped right now, but > I'll try to get an 0.9.3.1 out next week. Any other fixes worth > backporting while I'm at it? > I'm not sure how crazy you want to get with backporting bugfixes, but I looked through the logs and came up with a few candidates... 8901bce4 fixes a previous fix to our libtool script, but only affects specific MPI/Fortran compiler combinations 69cc60ee looks like a bugfix for the MeshfreeInterpolation stuff f108b893 fixed a bug in plotting discontinuous solutions in Exodus ac4b3b9d local_variable_indices bugfix 700f26fb fix for --disable-amr bec6e6da fixed bug in SerialMesh::stitching_helper e33b68ae fix for Solaris Studio -- John |
From: Derek G. <fri...@gm...> - 2014-05-09 22:50:55
|
Michael - can you really not use the Git version? A libMesh "release" really isn't much more special than any version in the Git repo... in fact all it means is that it's usually behind on bug fixes.... We've never used a "release" and we distribute libMesh to hundreds of customers daily without issue. Each time we update to a new version of libMesh we simply run all of our tests and verify that everything is still working well (which is actually something we do all day anyway because our developers all use the latest GitHub version of libMesh for development) and then push it out the door to our users. Derek On Fri, May 9, 2014 at 3:14 PM, John Peterson <jwp...@gm...> wrote: > > > > On Fri, May 9, 2014 at 2:23 PM, Roy Stogner <roy...@ic...>wrote: > > bugfix release for a regression this big. I'm swamped right now, but >> I'll try to get an 0.9.3.1 out next week. Any other fixes worth >> backporting while I'm at it? >> > > I'm not sure how crazy you want to get with backporting bugfixes, but I > looked through the logs and came up with a few candidates... > > 8901bce4 fixes a previous fix to our libtool script, but only affects > specific MPI/Fortran compiler combinations > 69cc60ee looks like a bugfix for the MeshfreeInterpolation stuff > f108b893 fixed a bug in plotting discontinuous solutions in Exodus > ac4b3b9d local_variable_indices bugfix > 700f26fb fix for --disable-amr > bec6e6da fixed bug in SerialMesh::stitching_helper > e33b68ae fix for Solaris Studio > > -- > John > > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find > out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Derek G. <fri...@gm...> - 2014-05-09 22:51:52
|
To be clear: we update libMesh about monthly... each time just updating to HEAD in the Git repo... Derek On Fri, May 9, 2014 at 4:50 PM, Derek Gaston <fri...@gm...> wrote: > Michael - can you really not use the Git version? A libMesh "release" > really isn't much more special than any version in the Git repo... in fact > all it means is that it's usually behind on bug fixes.... > > We've never used a "release" and we distribute libMesh to hundreds of > customers daily without issue. Each time we update to a new version of > libMesh we simply run all of our tests and verify that everything is still > working well (which is actually something we do all day anyway because our > developers all use the latest GitHub version of libMesh for development) > and then push it out the door to our users. > > Derek > > > > On Fri, May 9, 2014 at 3:14 PM, John Peterson <jwp...@gm...>wrote: > >> >> >> >> On Fri, May 9, 2014 at 2:23 PM, Roy Stogner <roy...@ic...>wrote: >> >> bugfix release for a regression this big. I'm swamped right now, but >>> I'll try to get an 0.9.3.1 out next week. Any other fixes worth >>> backporting while I'm at it? >>> >> >> I'm not sure how crazy you want to get with backporting bugfixes, but I >> looked through the logs and came up with a few candidates... >> >> 8901bce4 fixes a previous fix to our libtool script, but only affects >> specific MPI/Fortran compiler combinations >> 69cc60ee looks like a bugfix for the MeshfreeInterpolation stuff >> f108b893 fixed a bug in plotting discontinuous solutions in Exodus >> ac4b3b9d local_variable_indices bugfix >> 700f26fb fix for --disable-amr >> bec6e6da fixed bug in SerialMesh::stitching_helper >> e33b68ae fix for Solaris Studio >> >> -- >> John >> >> >> ------------------------------------------------------------------------------ >> Is your legacy SCM system holding you back? Join Perforce May 7 to find >> out: >> • 3 signs your SCM is hindering your productivity >> • Requirements for releasing software faster >> • Expert tips and advice for migrating your SCM now >> http://p.sf.net/sfu/perforce >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> >> > |
From: Derek G. <fri...@gm...> - 2014-05-09 22:56:02
|
Sorry for one more email on this topic... but if you want to see how we track libMesh revisions look at our repo: https://github.com/idaholab/moose See that libMesh directory? Notice how it has a Git has right next to it? We're using Git Submodules... and that hash the the current version of libMesh that we're using (ie that our customers are receiving) automatically just by checkout out our repo and running "git submodule init; git submodule update" (they actually run a small script in our repo that does that for them). In this way - all we need to do is update the hash of the version of libMesh we're using and all of our customers get the new revisions of libMesh automatically when they update their version of our software (and after running "git submodule update"). Nice and tidy - and no waiting on libMesh releases. Derek On Fri, May 9, 2014 at 4:51 PM, Derek Gaston <fri...@gm...> wrote: > To be clear: we update libMesh about monthly... each time just updating to > HEAD in the Git repo... > > Derek > > > On Fri, May 9, 2014 at 4:50 PM, Derek Gaston <fri...@gm...> wrote: > >> Michael - can you really not use the Git version? A libMesh "release" >> really isn't much more special than any version in the Git repo... in fact >> all it means is that it's usually behind on bug fixes.... >> >> We've never used a "release" and we distribute libMesh to hundreds of >> customers daily without issue. Each time we update to a new version of >> libMesh we simply run all of our tests and verify that everything is still >> working well (which is actually something we do all day anyway because our >> developers all use the latest GitHub version of libMesh for development) >> and then push it out the door to our users. >> >> Derek >> >> >> >> On Fri, May 9, 2014 at 3:14 PM, John Peterson <jwp...@gm...>wrote: >> >>> >>> >>> >>> On Fri, May 9, 2014 at 2:23 PM, Roy Stogner <roy...@ic...>wrote: >>> >>> bugfix release for a regression this big. I'm swamped right now, but >>>> I'll try to get an 0.9.3.1 out next week. Any other fixes worth >>>> backporting while I'm at it? >>>> >>> >>> I'm not sure how crazy you want to get with backporting bugfixes, but I >>> looked through the logs and came up with a few candidates... >>> >>> 8901bce4 fixes a previous fix to our libtool script, but only affects >>> specific MPI/Fortran compiler combinations >>> 69cc60ee looks like a bugfix for the MeshfreeInterpolation stuff >>> f108b893 fixed a bug in plotting discontinuous solutions in Exodus >>> ac4b3b9d local_variable_indices bugfix >>> 700f26fb fix for --disable-amr >>> bec6e6da fixed bug in SerialMesh::stitching_helper >>> e33b68ae fix for Solaris Studio >>> >>> -- >>> John >>> >>> >>> ------------------------------------------------------------------------------ >>> Is your legacy SCM system holding you back? Join Perforce May 7 to find >>> out: >>> • 3 signs your SCM is hindering your productivity >>> • Requirements for releasing software faster >>> • Expert tips and advice for migrating your SCM now >>> http://p.sf.net/sfu/perforce >>> _______________________________________________ >>> Libmesh-devel mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >>> >>> >> > |
From: Derek G. <fri...@gm...> - 2014-05-09 22:58:24
|
I think I've had too much coffee this afternoon... let's try that last email again... this time in English: Sorry for one more email on this topic... but if you want to see how we track libMesh revisions look at our repo: https://github.com/idaholab/moose See that libMesh directory? Notice how it has a Git hash right next to it? We're using Git Submodules... and that hash is the current version of libMesh that we're using (ie that our customers are receiving) automatically just by cloning our repo and running "git submodule init; git submodule update" (they actually run a small script in our repo that does that for them). In this way - all we need to do is update the hash of the version of libMesh we're using and all of our customers get the new revision of libMesh automatically when they update their version of our software (and after running "git submodule update"... again through a script). Nice and tidy - and no waiting on libMesh releases. On Fri, May 9, 2014 at 4:55 PM, Derek Gaston <fri...@gm...> wrote: > Sorry for one more email on this topic... but if you want to see how we > track libMesh revisions look at our repo: > https://github.com/idaholab/moose > > See that libMesh directory? Notice how it has a Git has right next to it? > We're using Git Submodules... and that hash the the current version of > libMesh that we're using (ie that our customers are receiving) > automatically just by checkout out our repo and running "git submodule > init; git submodule update" (they actually run a small script in our repo > that does that for them). > > In this way - all we need to do is update the hash of the version of > libMesh we're using and all of our customers get the new revisions of > libMesh automatically when they update their version of our software (and > after running "git submodule update"). > > Nice and tidy - and no waiting on libMesh releases. > > Derek > > > > On Fri, May 9, 2014 at 4:51 PM, Derek Gaston <fri...@gm...> wrote: > >> To be clear: we update libMesh about monthly... each time just updating >> to HEAD in the Git repo... >> >> Derek >> >> >> On Fri, May 9, 2014 at 4:50 PM, Derek Gaston <fri...@gm...> wrote: >> >>> Michael - can you really not use the Git version? A libMesh "release" >>> really isn't much more special than any version in the Git repo... in fact >>> all it means is that it's usually behind on bug fixes.... >>> >>> We've never used a "release" and we distribute libMesh to hundreds of >>> customers daily without issue. Each time we update to a new version of >>> libMesh we simply run all of our tests and verify that everything is still >>> working well (which is actually something we do all day anyway because our >>> developers all use the latest GitHub version of libMesh for development) >>> and then push it out the door to our users. >>> >>> Derek >>> >>> >>> >>> On Fri, May 9, 2014 at 3:14 PM, John Peterson <jwp...@gm...>wrote: >>> >>>> >>>> >>>> >>>> On Fri, May 9, 2014 at 2:23 PM, Roy Stogner <roy...@ic...>wrote: >>>> >>>> bugfix release for a regression this big. I'm swamped right now, but >>>>> I'll try to get an 0.9.3.1 out next week. Any other fixes worth >>>>> backporting while I'm at it? >>>>> >>>> >>>> I'm not sure how crazy you want to get with backporting bugfixes, but I >>>> looked through the logs and came up with a few candidates... >>>> >>>> 8901bce4 fixes a previous fix to our libtool script, but only affects >>>> specific MPI/Fortran compiler combinations >>>> 69cc60ee looks like a bugfix for the MeshfreeInterpolation stuff >>>> f108b893 fixed a bug in plotting discontinuous solutions in Exodus >>>> ac4b3b9d local_variable_indices bugfix >>>> 700f26fb fix for --disable-amr >>>> bec6e6da fixed bug in SerialMesh::stitching_helper >>>> e33b68ae fix for Solaris Studio >>>> >>>> -- >>>> John >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Is your legacy SCM system holding you back? Join Perforce May 7 to find >>>> out: >>>> • 3 signs your SCM is hindering your productivity >>>> • Requirements for releasing software faster >>>> • Expert tips and advice for migrating your SCM now >>>> http://p.sf.net/sfu/perforce >>>> _______________________________________________ >>>> Libmesh-devel mailing list >>>> Lib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >>>> >>>> >>> >> > |
From: John P. <jwp...@gm...> - 2014-05-12 16:14:31
|
On Mon, May 12, 2014 at 10:01 AM, Michael Povolotskyi <mpo...@pu...>wrote: > > May be meanwhile I learn how to use git. > This is definitely the way to go, especially if you need to contribute back to upstream at some point. Let us know if you have any questions. -- John |