[petsc-dev] plans for PETSc release

[Barry Smith]

   Jed,

   No PETSc developer/user has ever done or is likely ever to do all the cool testing you think will happen during a feature freeze; your fantasies are quite bizarre :-). Plus if there are testing environments not in the nightly builds that one "could" try during the freeze week the priority should be getting those environments into the nightly builds, not just testing on them one week a year.  This is also the first time that I was aware that we ever did a week long feature freeze in the past! We've always done the move it quickly into a release approach. 

  Barry


> On Apr 24, 2016, at 1:38 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>  Jed,
>> 
>> 1) I don't think having a feature freeze in master for a week is
>> tenable at all. Developers want to move stuff along into it and
>> continue work as they should. 
> 
> Having a freeze on 'master' doesn't prevent work on new features.  What
> difference does it make if the feature you just finished that won't be
> in a release for several months to a year is merged to 'next' or
> 'master' one week later?
> 
> But with a freeze on 'master', some developers might put some effort
> into testing with other packages and on weird machines.
> 
>> Plus developers don't like to think that stuff they are working and
>> just finishing won't be in a release for another year so will lobby
>> (as Lisandro did) to slip into the current release.
> 
> This is why I think we should announce when the feature merge window is
> closing, and follow it with a freeze in 'master'.
> 
>> 2) You seem to think that if we announce a freeze on master (or some
>> branch) dozens of disparate types of users will jump all over it and
>> do massive testing during that week finding all kinds of issues. Maybe
>> that happens with some package's users but not PETSc; we're lucky if
>> one or two people give it a half-hearted try out.
> 
> One thing some of us do around release time is to spin up builds with
> any downstream packages that we interact with and see if everything
> appears to be working correctly.  Sometimes that involves some patches
> to those packages, which also gives them a jump on being able to support
> the new version of PETSc when it starts nagging users to upgrade.  We
> also might build it on some weird machines that we have accounts on but
> don't regularly use.  We've definitely caught important things during
> the last-week feature freeze in the past.
> 
>>   This is why I think having a quick turn around time in preparing a
>>   release is best; so long as all nightly's run clean then I think we
>>   should "pop out" a release as quickly as possible on that.
> 
> Fuck it, Ship it.®
> 
> I think having a few days' feature freeze is due diligence that
> significantly improves quality of the release.
> 
>>  Your concern about breaking maint is admirable, next time we could
>>  use a different temporary branch name for this beast to prevent
>>  confusion.
> 
> I think we should use 'master'.  One week a year with no feature merges
> won't slow anyone down.