Re: Backport Policy

I believe I fall somewhere between Alex and Ben. As for deciding what to backport or not, I lean toward Alex's view of backporting as little as possible (and agree with his criteria). My reasoning is that all changes can have unforeseen consequences, which I believe is something to be actively

Re: Backport Policy

It seems to me that putting the burden of deciding on backports on the release manager would actually increase the amount of work required. Simply cutting the release on a particular date is pretty quick - however, examining tickets to determine whether or not a particular fix should be backported

Re: Backport Policy

I typically backport all bug fixes that cleanly apply and the risk is low. It's a judgement call, but many of the time, you can easily tell the risk is low. I think my argument on why we want to do this is "why not". I want our software to have less bugs! Letting release manager decides which pat

Re: [VOTE] Release Apache Mesos 1.6.1 (rc2)

+1 (binding) Ran through ASF CI. Red builds were known health check / check flaky tests. *Revision*: ae82dd5cc6f415916702897acfd3085b6387b118 - refs/tags/1.6.1-rc2 Configuration Matrix gcc clang centos:7 --verbose --enable-libevent --enable-ssl autotools [image: Failed]

Re: [VOTE] Release Apache Mesos 1.6.1 (rc2)

+1 (binding) Tested on our internal CI. All green. Tested on my Mac with both autotools and CMake, with gRPC enabled. Failed tests: HealthCheckTest.ROOT_INTERNET_CURL_HealthyTaskViaHTTPWithContainerImage HealthCheckTest.ROOT_INTERNET_CURL_HealthyTaskViaHTTPSWithContainerImage HealthCheckTest.ROOT

Re: Backport Policy

This is exactly where our views differ, Ben : ) Ideally, I would like a release manager to have more ownership and less manual work. In my imagination, a release manager has more power and control about dates, features, backports and everything that is related to "their" branch. I would also like