<div><div dir="auto">I added that milestone to some of the current docs MRs but it’s probably too tight, so I suggest to remove - it probably doesn’t matter much what’s in the tar all for docs so safer to have the current docs. We could have a patch release which updates the docs for release, once we’re happy with the docs build on main. </div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Satish Balay via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>> schrieb am So. 28. März 2021 um 20:58:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Perhaps I should not have kept a weekend deadline here.<br>
<br>
Lets use 'freeze': 'March 29 (Mon) 5PM CST' - but retain the release date 'March 30 5PM EST (we have March 31 - if needed)<br>
<br>
Satish<br>
<br>
 On Sun, 28 Mar 2021, Satish Balay via petsc-dev wrote:<br>
<br>
> A reminder!<br>
> <br>
> Satish<br>
> <br>
> On Tue, 9 Mar 2021, Satish Balay via petsc-dev wrote:<br>
> <br>
> > All,<br>
> > <br>
> > Its time for another PETSc release - due end of March.<br>
> > <br>
> > For this release [3.15], will work with the following dates:<br>
> > <br>
> > - feature freeze: March 28 say 5PM EST<br>
> > - release: March 30 say 5PM EST<br>
> > <br>
> > Merges after freeze should contain only fixes that would normally be acceptable to release workflow.<br>
> > <br>
> > I've created a new milestone 'v3.15-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.<br>
> > <br>
> > 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.<br>
> > <br>
> > 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.<br>
> > <br>
> > - if there are failures in stage-2 or 3 - and its no longer necessary to complete all the jobs - one can 'cancel' the pipeline.<br>
> > - 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:<br>
> >    - use the automatically started and paused 'merge-request' pipeline (or start new 'web' pipeline, and cancel it immediately)<br>
> >    - now toggle only the jobs that need to be run<br>
> >    - [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.<br>
> > <br>
> > Thanks,<br>
> > Satish<br>
> > <br>
> <br>
<br>
</blockquote></div></div>