[petsc-dev] plans for PETSc release

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> On Sun, 24 Apr 2016, Jed Brown wrote:
>
>> Satish Balay <balay at mcs.anl.gov> writes:
>> 
>> > On Sun, 24 Apr 2016, Jed Brown wrote:
>> >
>> >> Satish Balay <balay at mcs.anl.gov> writes:
>> >> 
>> >> > Master currently doesn't work as you describe. 
>> >> 
>> >> Why doesn't it work that way?  That was the philosophy when we adopted
>> >> this branching model years ago, it works reliably for many other
>> >> projects, and I thought it worked for us when we used it that way.  Did
>> >> something change?
>> >
>> > I was thinking about the number of times master was broken in the last month.
>> 
>> That's a workflow problem independent of releasing.  But if you feel
>> like 'master' is not stable enough for the promise we try to make about
>> 'master', putting that instability in 'maint' is pretty much the most
>> reckless thing possible.
>
> You are infering something I did not say. I did not merge instable
> stuff into maint.

I don't know how else to read a statement that you're concerned with the
low stability of 'master' in the last month and knowledge that there are
features pending in 'next'.

>>  The reason for a feature freeze on 'master' is
>> to bring its stability up to that of 'maint'.
>
> I don't think thats enforceable. As it turns out - its not even
> enforceable on maint - as this thread demonstrates.

I don't understand your definition of "enforceable".  If
petsc:integrators are not capable of respecting a feature freeze in
order to make a release, then that group should be downsized.  But that
doesn't seem to be the problem here.

>> >> > To me - currently we are at RC [yeah - witout a change in
>> >> > petscversion.h or a tag] - and RC to RELEASE should be via maint
>> >> > workflow - hence this update to maint.
>> >> 
>> >> Why should RC to release "be via maint workflow"?
>> >
>> > The thought is - one you want a release in the next few days - if a
>> > fix is critical then it should go in. If a fix can't be in 3.7.1 then
>> > it shouldn't go in.  And if a fix can be in 3.7.1 - then mostlikely it
>> > can wait till 3.7.1.
>> 
>> Presumably at least one of those is supposed to be 3.7.0.  But since you
>> haven't tagged v3.7, you're basically making 'maint' the new 'master',
>> which doesn't make any sense to me.
>
> I'm not making 'maint' the new master. I'm enforcing bugfix only policy.
> which is a maint policy.

You fast-forwarded 'maint' to 'master', thus 'maint' now has the same
stability as 'master'.  Since there was no freeze or other process to
increase the stability of 'master', why do we believe it is more stable
than on any random day?

I would prefer to have your "bugfix only policy" (aka. feature freeze)
to be applied to 'master' for a week (the RC timeline you propose
below).  Note one distinction that ABI-changing bug fixes can be allowed
during a feature freeze, but NOT on 'maint' (after release has been
tagged).  By fast-forwarding 'maint' before making a release, that
policy is confused.

> I see you are interpreting" RC=>buggy - so RC should never be in maint".

I interpret RC to mean "we don't trust this enough to call it a
release".  Releases have higher standards than RC.  If not, there
wouldn't be Candidates.  'maint' is supposed to always have the
stability of a release, therefore RC doesn't belong there.

> To me its equivalent of saying "3.6.3 is buggy - so it should have
> never be released - so only 3.6.4 shold have been released as 3.6"

All software has bugs.  Release implies a higher level of confidence
than a Release Candidate.

> Barry made an anouncement on encouraging users to test a few weeks
> back. I don't think that works.. We are attempting to release
> what we know is stable.

How do we know it's stable?  Because it looked good one night in the
nightlies?

>> > [there have been requests for TC testing - I was hoping we could be in
>> > this RC mode for a week - like a patch release test mode]
>> 
>> TC?
>
> RC

Great, but let's do that on 'master'.

> You can formulate all this stuff now. We never had a proper freeze policy.

We've had freezes in past releases, but yes, nothing was defined.  Let's
define it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160424/2f3f5800/attachment.sig>