Re: A quick follow-up release next week

> On 25 May 2019, at 11:40, Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se> wrote:
>
> On Sat, 25 May 2019, Ray Satiro wrote:
>
>> I prefer either of A) branch off and revert; or D) revert in master. My suggestion is if you are going to revert then roll them up into 1 like I did rather than have 5 reverts. I think it's clearer that way if you're reading the history to see what happened and why.
>
> Good advice I think. Let's see if someone else weighs in as well.
>
> After your input I think I'm on (D) now to make the git history easier to follow.

Since we don’t create a branch for every release, doing so for one would be
more confusing than reverting in master. I favor option D (with the commit
message clearly stating that the revert isn’t due to the commit in itself, but
due to proess).

>> To be clear I'm not suggesting wait a week before a patch release I'm
>> suggesting wait a week without any major reported problem in the latest
>> release before you open the feature window. Each time a release goes out
>> --including a patch release-- reset again.
>
> I hear you. My minor variation of that was to suggest that we can have a week post-release as a rule and allow us to overrule the full week with a public message saying the feature window has opened again - should we feel that need.
>
> Should we then extend the feature period one week at the far end so that it remains four weeks or should we narrow it down to 3:5 ? I'm rather indifferent and can think of reasons for either way.
>
>> For reference I read the last 5 years of release tags [1] and urgent patches have typically been within 5-10 days with just one at 2 days.

To take a play from another project I’m involved in, another way to deal with
this would be to branch off every release with a standardized name, like
RELEASE_7_65. Then tag the release in that branch, while master chugs along.
Should a patch release need to go out, the patch gets cherry-picked to the
release branch and a new release tagged (“backported” to use common
nomenclature). It does add more bookkeeping that the model of today, and
somewhat more work during releasing, but it adds more flexibility for these
sorts of situations.

We can still have feature freeze on master like today, but we could avoid have
a release thawing.

Not sure if I advocate it, just wanted to bring up an option on the table.

> It has however been made clear that the CI builds aren't covering all the setups that our user base is using - a number of issues showed up this time around in build combos and setups that we simple didn't test prior to release. More test coverage and more CI builds can help here.

Maybe we need some sort of automated.. matrix? .. of sorts which maps the
options we have in CI and what we have in autobuilds, to be able to find
blindspots?

cheers ./daniel
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-05-25