On Wed, Mar 25, 2020 at 8:23 PM Satish Balay via petsc-dev < petsc-dev@mcs.anl.gov> wrote:
> > > - 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 > 2554 is not merging. I will change the target. Thanks, Matt > !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-release > > > > 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 > > > > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>