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 <[email protected]> wrote:
On Sun, 24 Apr 2016, Jed Brown wrote:
Satish Balay <[email protected]> writes:
On Sun, 24 Apr 2016, Jed Brown wrote:
Satish Balay <[email protected]> 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?