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

[Satish Balay]

On Fri, 13 Mar 2020, Jed Brown wrote:

> Thanks for taking the lead on this, Satish.
> 
> Satish Balay via petsc-dev <petsc-dev at mcs.anl.gov> writes:
> 
> > All,
> >
> > We are to make a petsc release by the end of March.
> >
> > For this release [3.13], will work with the following dates:
> >
> > - feature freeze: March 27 say 5PM EST
> > - release: March 29
> >
> > Merges after freeze should contain only fixes that would normally be acceptable to maint workflow.
> >
> > I've changed the current milestone 'v3.13' to 'master' and created a new one 'v3.13-release'
> 
> Why this way?  Is the idea to bulk-offload everything we had intended to
> get in this release?  I feel like we should ping those merge
> requests/issues asking people to either commit to completing them or
> defer to post-release.

Currently there are about 50 MRs - likely most of them likely inactive.

My thought is to make the default 'mater' (i.e post release) - and use 'v3.13-release' for MRs we are actively working for the release. The other way of identifying inactive MRs or the ones not destined for release (and marking them as such) might not be easy. And usually the MR author is the best judge of this (inactive, active for release, active for later). And if active - can easily switch milestore to 'v3.13-release'

Sure - we should check with MR authors about this. In essence - this e-mail is part of that check.

BTW: I think we should work on getting as many MRs into release as feasible - but not scramble to get everything in.

Satish

> 
> > If you are working on a MR with the goal of merging before release - its best to use 'v3.13-release' 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:
> >    - start pipeline
> >    - immediately cancel the pipeline
> >    - 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
>