Greetings everyone.
First, I don't mean to point to anyone specifically here, but I just wanted to send a reminder about some things:
1. For ansible commit messages, could everyone try and do:
area/thing/host: short synopsis of the change <blank line> Longer explanation of the change.
I realize it's anoying when just fixing a syntax error from a previous commit or something, but when looking back at commit history it's really a lot nicer to see:
src.fedoraproject.org: fixing a typo in previous commit, Z should be Q
than
fix error
I realize it's fun to add amusing log entries, but I have had to look at git commit logs and it really makes it anoying to tell when something was done unless it's nice and clear. Feel free to add your funny line in the longer comment. :)
2. We are in freeze, so please get freeze breaks for any frozen hosts. Of course if something is down/on fire you can push the fix and then go back and make sure it gets approved. This will get a bunch easier when we have ansible repo in pagure.
3. Finally: hotfixes. We have a process for these... I don't know if it's too much of a pain or what, but it seems like sometimes we just don't use it. The basic process is:
* add ansible play to copy files from our repo to the filesystem * commit all the files you are going to touch. * commit in a second commit the changes for the hotfix. * push both with a comment about it. * run playbook.
Perhaps we could make this easier with a ansible hotfix role that already had all the ansible side and you just needed to commit the files and diffs? in any case, it makes my teeth itch when running ansible or applying updates drops a hotfix.
Thanks and I return you to your wed. :)
kevin
Hi,
Kevin Fenzi wrote:
- We are in freeze, so please get freeze breaks for any frozen hosts.
Of course if something is down/on fire you can push the fix and then go back and make sure it gets approved. This will get a bunch easier when we have ansible repo in pagure.
Until the ansible repo is in pagure, a git alias could probably make generating the patches for freeze break requests a little easier. Something like this:
git config alias.fbr \ "format-patch --subject-prefix='Freeze Break Request' --to=infrastructure@lists.fedoraproject.org"
And then you can generate a patch (or patches) via:
git fbr @{U}
or
git fbr -1
or any other options to the git format-patch command.
The resulting file(s) can then be sent via git send-email (or with any mail client that can read in files in mbox without munging them up).
Additional comments can be added to the patch file between the "---" and the diffstat, which is ignored when applying using git am.
If using git send-email, the default to address can be put in the sendemail config rather than embedded in the fbr alias, e.g.:
git config sendemail.to infrastructure@lists.fedoraproject.org
That's handy if patches other than freeze break requests are going to be sent.
On Wed, Mar 06, 2019 at 10:36:16PM -0500, Todd Zullinger wrote:
Hi,
Kevin Fenzi wrote:
- We are in freeze, so please get freeze breaks for any frozen hosts.
Of course if something is down/on fire you can push the fix and then go back and make sure it gets approved. This will get a bunch easier when we have ansible repo in pagure.
Until the ansible repo is in pagure, a git alias could probably make generating the patches for freeze break requests a little easier. Something like this:
git config alias.fbr \ "format-patch --subject-prefix='Freeze Break Request' --to=infrastructure@lists.fedoraproject.org"
And then you can generate a patch (or patches) via:
git fbr @{U}
or
git fbr -1
or any other options to the git format-patch command.
The resulting file(s) can then be sent via git send-email (or with any mail client that can read in files in mbox without munging them up).
Additional comments can be added to the patch file between the "---" and the diffstat, which is ignored when applying using git am.
If using git send-email, the default to address can be put in the sendemail config rather than embedded in the fbr alias, e.g.:
git config sendemail.to infrastructure@lists.fedoraproject.org
So I've been looking to use this as it sounds most helpful, thanks for sharing this! :)
If I understand it correctly, it comes down to adding these lines to the .git/config of the ansible repo: ''' [alias] fbr = format-patch --subject-prefix='FBR' --to=infrastructure@lists.fedoraproject.org [sendemail] to = infrastructure@lists.fedoraproject.org '''
I have one question though, what is the --to used for in the format-patch if git send-email doesn't support reading from it? (which is the case from what I saw yesterday)
Thanks again, Pierre
Hi,
Pierre-Yves Chibon wrote:
On Wed, Mar 06, 2019 at 10:36:16PM -0500, Todd Zullinger wrote:
Until the ansible repo is in pagure, a git alias could probably make generating the patches for freeze break requests a little easier. Something like this:
git config alias.fbr \ "format-patch --subject-prefix='Freeze Break Request' --to=infrastructure@lists.fedoraproject.org"
And then you can generate a patch (or patches) via:
git fbr @{U}
or
git fbr -1
or any other options to the git format-patch command.
[...]
If using git send-email, the default to address can be put in the sendemail config rather than embedded in the fbr alias, e.g.:
git config sendemail.to infrastructure@lists.fedoraproject.org
So I've been looking to use this as it sounds most helpful, thanks for sharing this! :)
If I understand it correctly, it comes down to adding these lines to the .git/config of the ansible repo: ''' [alias] fbr = format-patch --subject-prefix='FBR' --to=infrastructure@lists.fedoraproject.org [sendemail] to = infrastructure@lists.fedoraproject.org '''
Yeah, though using git config is the preferred way to do it And it's easier to document as a command, perhaps in the README.md or in infra-docs.
For ansible clones on batcave01, you could even create a config file in a shared location with the various recommended settings and then folks could just include that, via include.path, like:
git config inlcude.path /path/to/shared/config
I have one question though, what is the --to used for in the format-patch if git send-email doesn't support reading from it? (which is the case from what I saw yesterday)
The send-email command does read the "To:" field in the file(s) generated from format-patch. You should see a prompt asking "To whom should the emails be sent (if anyone)?" which allows you to add recipients in addition to the "To:" field in the patch file. If you skip that by pressing enter (and the next question on Message-ID), then send-email says:
(mbox) Adding to: infrastructure@lists.fedoraproject.org from line 'To: infrastructure@lists.fedoraproject.org'
Try that with the --dry-run option to confirm. If you don't see that, I'm curious what git version you have. I can't say with certainty if the ancient git versions on current RHEL releases behave the same (but if you're using one of those, there are many more useful features missing). ;)
But really, if you're using send-email, it's simpler to drop the format-patch --to option from the fbr alias, I think.
On Wed, 2019-03-06 at 14:17 -0800, Kevin Fenzi wrote:
- add ansible play to copy files from our repo to the filesystem
- commit all the files you are going to touch.
- commit in a second commit the changes for the hotfix.
- push both with a comment about it.
- run playbook.
* Make sure the patch makes it upstream, and preferrably in the next release of the software ☺
infrastructure@lists.fedoraproject.org