Thanks for taking the lead on this, Satish. Satish Balay via petsc-dev <[email protected]> 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. > 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
