[petsc-dev] petsc release plan for Sept/2020

[Patrick Sanan]

Hi Satish -

To follow up on the earlier discussion of what needs to be added the release checklist, as far as versioning:

The aim is to delete the old LaTeX users manual before the release, so things related to that obviously wouldn''t apply anymore. 

The TAO manual remains for now.

The custom front page of the (new) PDF manual has the version number hard-coded, so this needs to be updated manually in two places in

     src/docs/sphinx_docs/manual/anl_tech_report/first.inc


If I have time I'll see if we can't make that front page use the version number from the Sphinx docs. There is logic which is supposed to use the correct version number if it's a release version,
otherwise something verbose from git-describe (one of the open MRs makes that change to src/docs/sphinx_docs/conf.py). 



> Am 20.09.2020 um 18:43 schrieb Satish Balay via petsc-dev <petsc-dev at mcs.anl.gov>:
> 
> A reminder.
> 
> thanks,
> Satish
> 
> On Wed, 2 Sep 2020, Satish Balay via petsc-dev wrote:
> 
>> All,
>> 
>> We are to make a petsc release by the end of September.
>> 
>> For this release [3.14], will work with the following dates:
>> 
>> - feature freeze: Sept 27 say 5PM EST
>> - release: Sept 29
>> 
>> Merges after freeze should contain only fixes that would normally be acceptable to maint workflow.
>> 
>> I've created a new milestone 'v3.14-release'. So if you are working on a MR with the goal of merging before release - its best to use this tag with the MR.
>> 
>> And it would be good to avoid merging large changes at the last minute. And not have merge requests stuck in need of reviews, testing and other necessary tasks.
>> 
>> And I would think the testing/CI resources would get stressed in this timeframe - so it would be good to use them judiciously if possible.
>> 
>> - if there are failures in stage-2 or 3 - and its no longer necessary to complete all the jobs - one can 'cancel' the pipeline.
>> - if a fix needs to be tested - one can first test with only the failed jobs (if this is known) - before doing a full test pipeline. i.e:
>>   - use the automatically started and paused 'merge-request' pipeline (or start new 'web' pipeline, and cancel it immediately)
>>   - now toggle only the jobs that need to be run
>>   - [on success of the selected jobs] if one wants to run the full pipeleine - click 'retry' - and the remaining canceled jobs should now get scheduled.
>> 
>> thanks,
>> Satish
>> 
>