Re: [petsc-dev] plans for PETSc release

[Karl Rupp]

Hi,

I'm not Jed, so apologies for adding my two cents on this...
> 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. 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.

If that is a concern, one could still fork a branch off master, which 
gets stabilized for a week and merged to maint once the release is out. 
The price to pay is the extra backporting to master, which is just as 
much a nuisance as a feature freeze.

On the other hand, a feature freeze for a week is a perfect opportunity 
for improving documentation and other work that will not break the code. 
And even if one prefers to keep coding, new features can still be put in 
next for testing. Particularly if communicated in advance ("Hey, we will 
have a feature freeze in 7 days and plan to release in 10 days"), people 
can easily arrange things. I think Lisandro's feature would have been 
ready on time if he had known 7 days in advance.

Another thing we might want to discuss at a later point is whether we 
want to rethink our release intervals and aim for ~6 months instead of 
~12 months. If we put some efforts into automating most of deployment, 
we can do this without the tedious manual work Satish has to go through.


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.

Even if it's only two, it's better than zero. Providing the possibility 
for users to test (e.g. against their own set of nightly tests) is 
better than not providing the option at all.


    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.

I agree that a release should become a painless procedure and be mostly 
automated.


   Your concern about breaking maint is admirable, next time we could use a 
different temporary branch name for this beast to prevent confusion.

Thanks.


You are being a bit pedantically Roscoe in this thread.

;-) Jed is not proposing something that induces more effort, just a more 
coordinated plan of moving things when and where.

Best regards,
Karli







On Apr 24, 2016, at 12:51 PM, Satish Balay <ba...@mcs.anl.gov> wrote:

On Sun, 24 Apr 2016, Jed Brown wrote:

Satish Balay <ba...@mcs.anl.gov> writes:

On Sun, 24 Apr 2016, Jed Brown wrote:

Satish Balay <ba...@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.

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.


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.


Anyway, if we allow 3.7.0 to ship with no more stability than a first
RC,

Again you are misinterpreting my statement.

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

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"

we're basically telling users they shouldn't even bother trying
until *.*.1 releases.  I think that's a cop out.  Having a feature
freeze, clearing out 'next', and encouraging users to test 'master' is a
good way to make sure the *.*.0 releases are better.

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.

[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


I think we should have a week of feature freeze (no new features to
'master' or 'next') prior to tagging a release.  But tag the release on
'master'.

I'd also argue we're clearly not at RC because new features (currently
in 'next') are still being merged.

I was trying to avoid that.

Well, there were several feature branches in 'next' before you
fast-forwarded 'maint' so it's not all a surprise.

After changing 'maint', you still
advised Lisandro to merge new features to 'next' so that they could
later graduate for the release.

If they can go into 3.7.1 - then they should be merged by then. [We've
added new features in patch releases before - if they didn't modify
exisiting API].

Normally the new features are more minor than a TS overhaul, but it can
be done.

As for pending merges, what is the status of these branches (in 'next',
but not yet in 'master')?

[...]

The same 'maint' criteria. If they can't go into a patch release -
they shouldn't be merged to maint. If they can - then they can be
merged [if they can be tested in maint again - or wait for next patch
release]

Normally we rewind 'next' when making a release.  These features either
need to be merged or are abandoned for now (can try again for 3.8).  If
they are 'maint'-eligible, then they should be merged for 3.7.  Cleaning
up those loose ends is one of the things supposed to happen during the
freeze.

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

I was attempting that.

Satish

I was trying to avoid this last minuite push to merge features - just
before the release.

Of course, which is why I prefer a feature freeze of about a week before
tagging a release.

Barry can override me on this - [If have to spin a tarball on monday]
I won't merge anything into maint - unless they are tested fixes. And
deferer other valid things to patch1

I know that when target dates slip, it's annoying and tempting to just
declare good enough.  But why not spin an RC on Monday and tag the
release later in the week?