Mailing List Archive

A question: Would it be easier for all this if we moved to being Github canon?

> On Mar 4, 2022, at 5:08 AM, Stefan Eissing <stefan@eissing.org> wrote:
>
> We should improve our backport procedure and provide guidance on how to use it after the next release.
>
> Post-mortem dbm backport:
> - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO()
> - the incomplete patch was voted on and accepted, as local tests do not have the full CI checks
> - Jim applied the voted on backport patch
> - CI failed
> No one did anything really wrong. We did just not apply the CI tools available until the damage was done.
>
> As noted in the related thread, backport proposal should really be PRs on github. Those are checked by
> our CI and a PR can easily be improved by adding submits to the branch it is based on. In addition, we
> get the github UI for review and comments. Should be a win for all.
>
> Kind Regards,
> Stefan
>
>

On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> wrote:
>
> A question: Would it be easier for all this if we moved to being Github canon?

I think it is much more straightforward. The original work, reviews
and travis results are all in the same place and nothing is copied
around.
I have had the same thought a few times this week. But I was hesitant
to reopen that thread/discussion because I'm pessimistic we can get
anywhere on it.

On 04 Mar 2022, at 12:08, Stefan Eissing <stefan@eissing.org> wrote:

> We should improve our backport procedure and provide guidance on how to use it after the next release.
>
> Post-mortem dbm backport:
> - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO()
> - the incomplete patch was voted on and accepted, as local tests do not have the full CI checks
> - Jim applied the voted on backport patch
> - CI failed
> No one did anything really wrong. We did just not apply the CI tools available until the damage was done.

Just to confirm - no damage was done.

We have a thorough, multistep process that ensures damage is not done. We do the work first on trunk and our CI, then we propose it for backport on trunk and it is tested again by multiple people through their votes. Then it hits our stable branch and then it gets tested by even more people, and our CI. Then it’s tested again when we propose a release. If we slip through all that, only then is damage done.

> As noted in the related thread, backport proposal should really be PRs on github. Those are checked by
> our CI and a PR can easily be improved by adding submits to the branch it is based on. In addition, we
> get the github UI for review and comments. Should be a win for all.

Github PRs are easy to use, and it’s entirely reasonable to use github to handle a backport if you choose to do so.

Github PRs also have simple interfaces, like this one:

curl https://[url-of-pr].diff | patch -p1

I am however strongly opposed for Github to be our only promotion process.

CI is great right until the point you get your first unrelated test failure, then it is a nightmare. The collectd project was completely stuck unable to merge a single PR for months and months because their CI broke and nobody had access to fix it. Github presented a “computer says no” button and the project ground to a complete halt. The project is now so backlogged that the chances of getting anything reviewed are slim.

https://www.mail-archive.com/search?l=collectd@verplant.org&q=subject:%22Re%5C%3A+%5C%5Bcollectd%5C%5D+SNMPv3%5C%2BDTLS+support+for+collectd%5C-snmp%22&o=newest&f=1

It is inevitable that at some point the generosity of the people supplying the CI will run out, and CI will stop working. We cannot allow ourselves to be jammed up because of this.

To sum up:

+1 on the option to use Github PRs for backports.
-1 to mandating the use of Github PRs for backports.

Regards,
Graham
—

>
> To sum up:
>
> +1 on the option to use Github PRs for backports.
> -1 to mandating the use of Github PRs for backports.
>
For backports specifically: Is a middle ground to not have GH block merging
based on CI checks? This way PRs could be required, so revieers (the same
reviewers we have today in STATUS) can see test results.

Or is there something else objectionable about doing the work in a PR?

On Sun, Mar 06, 2022 at 05:56:36PM +0200, Graham Leggett wrote:
> I am however strongly opposed for Github to be our only promotion process.
>
> CI is great right until the point you get your first unrelated test failure, then it is a nightmare. The collectd project was completely stuck unable to merge a single PR for months and months because their CI broke and nobody had access to fix it. Github presented a “computer says no” button and the project ground to a complete halt. The project is now so backlogged that the chances of getting anything reviewed are slim.
>
> https://www.mail-archive.com/search?l=collectd@verplant.org&q=subject:%22Re%5C%3A+%5C%5Bcollectd%5C%5D+SNMPv3%5C%2BDTLS+support+for+collectd%5C-snmp%22&o=newest&f=1
>
> It is inevitable that at some point the generosity of the people
> supplying the CI will run out, and CI will stop working. We cannot
> allow ourselves to be jammed up because of this.

I assume the ASF infra budget is still paying for Travis capacity since
there is no free service there any more (beyond an initial N thousand
hours per account), and they were in the past:

https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci

AIUI you can configure github to allow merges even if tests fail, though
I'm not familiar with that, has anybody played with the settings there?

Regards, Joe

On 3/7/22 12:23 PM, Joe Orton wrote:

>
> AIUI you can configure github to allow merges even if tests fail, though
> I'm not familiar with that, has anybody played with the settings there?
>

Haven't played with them, but the below looks like a good starting point:

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests

Regards

Rüdiger