[petsc-dev] plans for PETSc release

[Barry Smith]

> On Apr 24, 2016, at 3:26 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>   No PETSc developer/user has ever done or is likely ever to do all
>>   the cool testing you think will happen during a feature freeze;
>>   your fantasies are quite bizarre :-). 
> 
> Well, I've done this at least with PFLOTRAN and libMesh/MOOSE for
> various previous releases.  I'm pretty sure Lisandro has done similar
> with some of his packages and Matt with PyLith.  I've tested on NERSC
> and ALCF early access machines.  I thought others had been doing similar
> as time and access allowed.
> 
>>   Plus if there are testing environments not in the nightly builds
>>   that one "could" try during the freeze week the priority should be
>>   getting those environments into the nightly builds, not just
>>   testing on them one week a year.
> 
> The machines I'm thinking of are managed by other people and typically
> not convenient to have running automated tests (sometimes due to
> security like cryptocard logins).  When we test a version there, we're
> testing both that version of PETSc and the environment on the machine,
> which are often being "upgraded" periodically.

   There is still no excuse for not during regular testing there. Maybe not daily but at least once a week and automating it as much as possible. For example I can envision each Wednesday morning at 9 am Satish receiving an email that says: Log into mira.alcf.anl.gov and run the script testmira to start the test build. Then that script runs all the compiles and ships off to the dashboard all results without requiring further actions by a human. Each Thursday Jason gets a similar email for hopper etc. It is not perfect but it is better than someone manually doing tests when they are inspired. The timing of these pseudo automated testing could be increased around releases.

> 
>>   This is also the first time that I was aware that we ever did a
>>   week long feature freeze in the past! We've always done the move it
>>   quickly into a release approach.
> 
> We've usually had precise deadlines announced in advance, with the
> release being tagged some days later.  It was a literal code freeze back
> in v3.3, but you're right that it has been more variable and ad-hoc than
> I remembered.

   If you look at 3.3 log merges I suspect you'll see that the "code freeze" was more "in spirit" and plenty of stuff that was not "fixes" got pushed during that long time frame.

> 
> 
> v3.6:
> 
>  2015-05-28: bsmith on petsc-dev "Satish and I are planning a PETSc
>  release by Friday June 5"
> 
>  2015-06-09 Release tagged
> 
> v3.5:
> 
>  2014-06-12: bsmith on petsc-dev "Please get all changes into master
>  before 9pm central time USA on Sunday June 15th that you would like in
>  the release. At that time Satish will make a release branch and the
>  only changes allowed in that release branch will be bug fixes that do
>  not change the API."
> 
>  2014-06-30: Release tagged
> 
> v3.4 seems to have been relatively stealth, though there was plenty of
> off-list discussion.  This was shortly after we switched to Git.
> 
> v3.3:
> 
>  2012-05-17: bsmith on petsc-dev "Recall that we are in a phase of a
>  code freeze that means do not push random new code to petsc-dev, push
>  only bug fixes and clean up to petsc-dev.  By all means keep on with
>  code development, just don't push the new stuff to petsc-dev.
> 
>  We hope to make the release repository (and then tarball) next
>  Wednesday May 23. So please do be checking the nightly builds and
>  making fixes to petsc-dev."
> 
>  2012-06-05: Release tagged