> On 25 May 2019, at 11:40, Daniel Stenberg via curl-library > <curl-library@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
