...

- feature freeze: March 27 say 5PM EST

A reminder, feature freeze is in 2 days. I see the following MRs with milestone: v3.13-release !2598 Add Sphinx docs and port Developers Manual !2614 Knepley/feature dm remove hybrid !2626 More support for not needing to set PETSC_DIR yet build with PETSc, also... !2634 WIP: Balay/release 3.13 revert to dev !2554 Knepley/feature fe lagrange gll !2367 WIP: Add sample file that demonstrates use of CMake and pkg-config to build a PETSc application I'm hoping all v3.13-release MRs will complete testing and reviews (approvals) before the freeze. Thanks, Satish On Fri, 20 Mar 2020, Satish Balay via petsc-dev wrote:

An update:

https://gitlab.com/petsc/petsc/-/merge_requests?milestone_title=v3.13-releas...

We have a week to go. And have about 47 MRs, with 12 marked as 'v3.13-release' milestone.

Likely the milestone is not correctly set for some MRs - if so - please update the MR.

And I see some MRs with significant code changes. Hopefully we can process them early [and not have large changes close to freeze date].

Satish

On Fri, 13 Mar 2020, Satish Balay via petsc-dev wrote:

...

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'

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