On Fri, 11 May 2012, Barry Smith wrote: > > On May 11, 2012, at 11:57 AM, Jed Brown wrote: > > > It'll necessarily be a branch after release. > > Yes, but as little of a branch as possible. > > > I thought we have branched at or near feature freeze in the past. > > I don't feel we are stable enough yet to make that branch. There is lots > of shit that needs to be fixed and I don't want that shit represented both in > the branch and the dev separatenly. I want the branch made only when we think > the branch is pretty much done.
making a release clone now is not a big deal [only issue is updating the nightly builds with the correct clone] And Wrt commits - one would have to make sure appropriate ones go into petsc-3.3 clone. And they will be pulled/merged into petsc-dev [and there won't be any dulicate commits as would happen in svn-branches] The primary thing that avoiding a clone 'today' will acomplish is: perhaps push everyone to concentrate more on release related issues. But I guess most dont need this push. Satish > > > > > Do you just not want to have to update your builds for a new clone? > > No, that is not the reason. > > Barry > > > > > On May 11, 2012 11:54 AM, "Barry Smith" <bsmith at mcs.anl.gov> wrote: > > > > On May 11, 2012, at 11:46 AM, Dmitry Karpeev wrote: > > > > > On Fri, May 11, 2012 at 11:40 AM, Barry Smith <bsmith at mcs.anl.gov> > > > wrote: > > > > > > Ok, in order to get the release out the door, please do not push > > > development work to petsc-dev. Only push fixes and removal of dead code > > > (DMMG for example). Also please run extensive tests and check the > > > nightly builds. > > > > > > You can continue to do development; just continue to PULL into your > > > development repository but don't PUSH to the master. To apply fixes to > > > petsc-dev use another repository or one of "the cool guys" (Sean, Jed, > > > and Matt's) way of only pushing up some changes. > > > > > > Questions? Send them. > > > Why not set up a release repo and push fixes there, while continuing to > > > push development changesets to petsc-dev? > > > > All the fixes that go in the "release repo" also need to go into the > > "development repo", I don't want to have any chance of the "release repo" > > becoming a branch; I want it to only be an earlier version of the > > development repo. > > > > Barry > > > > > > > Dmitry. > > > > > > Thanks > > > > > > Barry > > > > > > > > > Note: since the threaded code and gpu code continues to be in flux we > > > will be continuing to support the use of those only in petsc-dev, not in > > > the next petsc-release. > > > > > > > > > On May 5, 2012, at 9:51 PM, Matthew Knepley wrote: > > > > > > > On Sat, May 5, 2012 at 10:32 PM, Jed Brown <jedbrown at mcs.anl.gov> > > > > wrote: > > > > On Fri, May 4, 2012 at 12:57 PM, Peter Brune <prbrune at gmail.com> > > > > wrote: > > > > Jed, what else needs to be done with respect to getting all the SNES > > > > context into DM? I notice that, for instance, SNESSet/GetFunction is > > > > still mostly using the ops in SNES rather than the ones in SNESDM. > > > > > > > > I had a temporary option -snes_kspcompute to make the dispatch go > > > > through SNESDM. The main holdup now is -snes_grid_sequence, but I'm > > > > banging away at ex48 again, so I should be able to get it all working > > > > shortly. (I have ex48 running without DMMG, but some functionality is > > > > missing now, like changing the physics in the middle of the MG > > > > hierarchy.) > > > > > > > > Can we commit to a hard deadline? I would like the freeze for testing > > > > May 11, and clone and release May 14. > > > > > > > > Matt > > > > > > > > -- > > > > What most experimenters take for granted before they begin their > > > > experiments is infinitely more interesting than any results to which > > > > their experiments lead. > > > > -- Norbert Wiener > > > > > > > > > >
