Ansible release process feedback

Archives Ansible Developer
1

Hi

I just want to start a constructive feedback about the latest Ansible release process.

The last 3 major releases, our user experience was not quite well and we rolled back.

It makes use feel scary about upgrading to major releases, but on the other hand, we all like the new modules and features of new releases. And I guess we are not alone with this feelings. So I wanted to ask how Ansible Inc can improve the release process. I want to make 3 proposals, how the release process can be improved.

1. Plan a release? Let us know!

We would like to test new major releases but didn’t had a change to test 1.8 before the release because we didn’t knew when it will be released. If you have made an announcment here like: “Please test it now for release!” That would be great. A even better approach would be tagging an RC, see below.

2. Release branch for major releases only

The current Ansible git branching model looks weird. I do not understand why you make a branch for every release, especially minor release. It looks to me, you are trying to adopt the “linux kernel git workflow” but doing it not quite right.

My suggestion is:

  • make a branch only for major release e.g. “1.7.x” and make a tag on that commit e.g. “v1.7.0”
  • only bug fixes get into this release branch, after some commits (or every commit) you tag a minor release. e.g. “v1.7.1”
  • once you have new major release like e.g. v1.8.0 you will deprecate the 1.7.x branch (or alternatively, make it an LTS release)

This workflow is nice and clean.

3. GitHub PR Release Labels

Currently we only see labels like prio 1, prio 2, prio 3. But we have no clue if and when the PR will get merged It would be great if you could label a PR like “1.9.” so we know, it is planned for 1.9 release to be merged in. An advantage would be, you will also get a burn down chart (and we also see an estimate release date).

That’s it. To be clear, we are not saying your release process is bad. We just want to improve it and to make Ansible releases a breeze.

Thanks for your understanding.

Yours
René

2

Hi Rene,

Bugs occur in each release and we are doing the best we can on this while still trying to accomodate everyone’s requests and correct important items quickly.

If anyone has concerns about how things are managed, please contact us off list, I would ask that this not be the forum to discuss such concerns.

I’m going to decline to give a timetable on labels – the point of having a queue is to work on things in order, but we do not estimate every single ticket and add them up, and we also could have something more important come in tomorrow. The queue is honest – it’s a LARGE queue. Dates and promises would not be.

If you want to see things merged more quickly, the way to get that done is actually to contribute less – what you see right now is a result of a GIANT TON of incoming patches.

What differentates Ansible a lot from a quite a few open source projects is we DO test incoming features and review things pretty heavily, and a lot of submissions are great quality, and some are not. Thus it’s not possible to tell you when something is going to come in.

Anyway, economies of scale.

Thankfully with Ansible about 20% of users consume the development branch full time, allowing for near-constant user testing in addition to automated tests.

You’re welcome to monitor commit logs and GitHub activity to see when new things to come in - unfortunately at our volume we cannot send an email to the project list every time every commit comes in, though this is exactly what the commit logs are for.

Hope this makes sense. While I understand a desire to see when things are going to be merged, the existing queue is a mechanism to give visibility into that, as was the split into the two module repos, etc.

Lots of good things, but you do need to understand Ansible is one of the top 100 most forked projects on GitHub, and one of the top 5 for contributors last year - that is going to mean not everything can get in instantaneously.

3

" I do not understand why you make a branch for every release, especially minor release. It looks to me, you are trying to adopt the “linux kernel git workflow” but doing it not quite right."

On this:

This makes it easier to apply changes and compare differences in releases for us.

If you don’t like the extra branches, ignore them.

They are not hurting anything.

4

Hi Michael

I am writing this to the list, because I don’t like hide things. Ansible Inc. does a FANTASTIC JOB! THANKS FOR ALL THE WORK, really! Nothing to hide!

Bugs occur in each release and we are doing the best we can on this while still trying to accomodate everyone’s requests and correct important items quickly.

Yes, I am really sure you do! I mean the project is still young and growing fast. And it is not easy dealing with the community, but we are here to help you guys out, there are great devs out there! Let us help you. Let’s make the best software we can, the best configuration management on planet.

I’m going to decline to give a timetable on labels – the point of having a queue is to work on things in order, but we do not estimate every single ticket and add them up, and we also could have something more important come in tomorrow. The queue is honest – it’s a LARGE queue. Dates and promises would not be.

Yes I see. I would like to offer you, maintaining Debian related modules, test related PR. giving feedback, and sign-off PRs which I think is good to merge. If I am doing wrong, blame me. Maybe others will join this process.

If you want to see things merged more quickly, the way to get that done is actually to contribute less – what you see right now is a result of a GIANT TON of incoming patches.

What differentates Ansible a lot from a quite a few open source projects is we DO test incoming features and review things pretty heavily, and a lot of submissions are great quality, and some are not. Thus it’s not possible to tell you when something is going to come in.

Appreciate that! Maybe you could create another label, like “community-review” and “maintainer-review”, so the community can review it first for their go or no-go. This would actually great for module-extras. Even a voting process on a PR would a possible help. label “open for vote” simple +1/-1 voting for feature or give gerrit a try for repo modules-extras.

I cannot decide, what is good for the project. But those are my $ 0.02 . Can not make this more clear I am impressed what an amazing job Ansible Inc does. We are here to help. You decide when and how. Thanks.

Regards
René