> > - 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-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
> > 
> 

Reply via email to