Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
On Sat, 9 Mar 2019 at 22:19, Neal Gompa ngompa13@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
On Sun, Mar 10, 2019 at 10:53 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 9 Mar 2019 at 22:19, Neal Gompa ngompa13@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Even for exclusively Python 2? Koji isn't building Python 3 components in EPEL at all right now, as there's too much stuff missing for that to work anyway.
On Sun, 10 Mar 2019 at 10:55, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Mar 10, 2019 at 10:53 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 9 Mar 2019 at 22:19, Neal Gompa ngompa13@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Even for exclusively Python 2? Koji isn't building Python 3 components in EPEL at all right now, as there's too much stuff missing for that to work anyway.
OK in that case, we can look at adding the missing stuff afterwords.
On Sun, Mar 10, 2019 at 10:57 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sun, 10 Mar 2019 at 10:55, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Mar 10, 2019 at 10:53 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 9 Mar 2019 at 22:19, Neal Gompa ngompa13@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Even for exclusively Python 2? Koji isn't building Python 3 components in EPEL at all right now, as there's too much stuff missing for that to work anyway.
OK in that case, we can look at adding the missing stuff afterwords.
So then, no objection to me merging and submitting updates to Bodhi for this now then?
-- 真実はいつも一つ！/ Always, there's only one truth!
On Sun, 10 Mar 2019 at 10:59, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Mar 10, 2019 at 10:57 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sun, 10 Mar 2019 at 10:55, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Mar 10, 2019 at 10:53 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 9 Mar 2019 at 22:19, Neal Gompa ngompa13@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Even for exclusively Python 2? Koji isn't building Python 3 components in EPEL at all right now, as there's too much stuff missing for that to work anyway.
OK in that case, we can look at adding the missing stuff afterwords.
So then, no objection to me merging and submitting updates to Bodhi for this now then?
None from me. I was just worried you might have side package needs..
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Please wait for Tues/Wed for everything to allow rel-eng and infra to replay. It should also go to rawhide first.
Not everyone works on the weekend, and Monday is often catching up from issue from the weekend for people.
Peter
On Sun, Mar 10, 2019 at 11:42 AM Peter Robinson pbrobinson@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Please wait for Tues/Wed for everything to allow rel-eng and infra to replay. It should also go to rawhide first.
Not everyone works on the weekend, and Monday is often catching up from issue from the weekend for people.
I'm not pushing to stable automatically, but they are proposed for syncing out to updates-testing:
* Fedora 30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b2e124a4a * Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-940d3922ce * Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c4107ac9d3 * Fedora EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-798356a949 * Fedora EPEL 6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-210b4d1b32
This should give people the opportunity to test the new version and get it pushed once it's validated.
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Please wait for Tues/Wed for everything to allow rel-eng and infra to replay. It should also go to rawhide first.
Not everyone works on the weekend, and Monday is often catching up from issue from the weekend for people.
I'm not pushing to stable automatically, but they are proposed for syncing out to updates-testing:
I think pushing it at all with such little notice and on a weekend is disingenuous, it wasn't even 24 hrs between when you sent the above email and merging your own PR with out a single comment on the PR from either the koji maintainers (of which you're not one, and I believe one of them requested on IRC that you don't) or the rel-eng team. Even on a week day, due to timezones and people having things like getting the Beta done, I would expect you to wait a good 48 hours after posting to the list, and if done on a weekend 48 hours of working time to ensure review and response before just pushing it anyway.
What's more you should at LEAST just push it to rawhide first and let it bake there for some time before then shoving it out to every release!
- Fedora 30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b2e124a4a
- Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-940d3922ce
- Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c4107ac9d3
- Fedora EPEL 7:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-798356a949
- Fedora EPEL 6:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-210b4d1b32
This should give people the opportunity to test the new version and get it pushed once it's validated.
But it doesn't give rel-eng and the infrastructure teams to review your changes, and we're also in freeze which means if there's something in existing stable builds that needs to be fixed for that it's quite likely that they may have to revert it all, bump an epoch to get things working again rather than having the re-validate and entire stack.
PLEASE do not do this sort of stuff, it's not helpful or kind to the teams that have to deal with the infra and releases. There's no rush to get it out, it should go through the process of the maintainers reviewing your changes, it being tested in rawhide and then eventually making it to a stable release. Why did you do this? People have asked you explicitly not to do this stuff in the past yet you keep ignoring it.
Peter
On Sun, Mar 10, 2019 at 7:12 PM Peter Robinson pbrobinson@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Please wait for Tues/Wed for everything to allow rel-eng and infra to replay. It should also go to rawhide first.
Not everyone works on the weekend, and Monday is often catching up from issue from the weekend for people.
I'm not pushing to stable automatically, but they are proposed for syncing out to updates-testing:
I think pushing it at all with such little notice and on a weekend is disingenuous, it wasn't even 24 hrs between when you sent the above email and merging your own PR with out a single comment on the PR from either the koji maintainers (of which you're not one, and I believe one of them requested on IRC that you don't) or the rel-eng team.
I specifically waited for a response from someone in the releng/admin team. The packaging is literally copied from upstream, which has already been beaten to death under multiple pull requests. In addition, the PR had some review from someone before I asked about merging it.
When Stephen gave me the okay, I went with it. I specifically asked because I wanted permission before pushing it to testing.
And for what it's worth, the original 1.17.0 update to Koji in Rawhide was broken. It did a directory -> file replacement improperly which causes rpm to choke. Moreover, the transition wasn't even necessary because the directory was completely unused and had been for a while.
All I did was synchronize what upstream offered, and made a small tweak based on the feedback in the PR.
Even on a week day, due to timezones and people having things like getting the Beta done, I would expect you to wait a good 48 hours after posting to the list, and if done on a weekend 48 hours of working time to ensure review and response before just pushing it anyway.
What's more you should at LEAST just push it to rawhide first and let it bake there for some time before then shoving it out to every release!
- Fedora 30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b2e124a4a
- Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-940d3922ce
- Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c4107ac9d3
- Fedora EPEL 7:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-798356a949
- Fedora EPEL 6:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-210b4d1b32
This should give people the opportunity to test the new version and get it pushed once it's validated.
But it doesn't give rel-eng and the infrastructure teams to review your changes, and we're also in freeze which means if there's something in existing stable builds that needs to be fixed for that it's quite likely that they may have to revert it all, bump an epoch to get things working again rather than having the re-validate and entire stack.
First of all, you're blowing it way out of proportion. It's only in testing, and that's pretty much the only way anyone can really see whether it works. And like it or not, it has to make its way into stable releases at some point, so that all the stuff can use it.
I disabled autopushing precisely so that there's no accidental pushing to stable updates. The worst thing that can happen is that we have to unpush the update from testing. Seriously, that's really not the end of the world.
Nowhere did I say that releng needs to deploy this RIGHT NOW. Having this in rawhide and F30 updates-testing makes it possible for the dependency map for Python 2 to cleanup even more, allowing the Python SIG to continue its work to clean out Python 2 subpackages in Fedora 30/31.
PLEASE do not do this sort of stuff, it's not helpful or kind to the teams that have to deal with the infra and releases. There's no rush to get it out, it should go through the process of the maintainers reviewing your changes, it being tested in rawhide and then eventually making it to a stable release. Why did you do this? People have asked you explicitly not to do this stuff in the past yet you keep ignoring it.
Actually, for your information, this is literally the first time I've done this for infrastructure. No one has ever said anything like that to me before. I'm going to leave it at this, because if I say more, I'll probably be a lot less charitable.
On Sun, Mar 10, 2019 at 11:42 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Mar 10, 2019 at 7:12 PM Peter Robinson pbrobinson@gmail.com wrote:
Hey all,
I've proposed a pull request to switch our Koji package to use Python 3 wherever possible: https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji, which accounts for all the variations (Py2 Koji + Py3 client for Fedora < 30, Py3 Koji + client + Py2 API for Fedora 30+, Py2 Koji for EPEL).
I'd like to merge this in and submit updates for all currently supported releases we ship the Koji package to (Fedora and EPEL).
Note that this is independent of testing and upgrading the infrastructure. But I'd like to merge this in now so that we could look at having staging Koji switch over now.
Could you wait til Tuesday/Wednesday for EPEL, we are in the middle of putting the python36 there and various packages build funny until we are done.
Please wait for Tues/Wed for everything to allow rel-eng and infra to replay. It should also go to rawhide first.
Not everyone works on the weekend, and Monday is often catching up from issue from the weekend for people.
I'm not pushing to stable automatically, but they are proposed for syncing out to updates-testing:
I think pushing it at all with such little notice and on a weekend is disingenuous, it wasn't even 24 hrs between when you sent the above email and merging your own PR with out a single comment on the PR from either the koji maintainers (of which you're not one, and I believe one of them requested on IRC that you don't) or the rel-eng team.
I specifically waited for a response from someone in the releng/admin team. The packaging is literally copied from upstream, which has already been beaten to death under multiple pull requests. In addition, the PR had some review from someone before I asked about merging it.
When Stephen gave me the okay, I went with it. I specifically asked because I wanted permission before pushing it to testing.
And for what it's worth, the original 1.17.0 update to Koji in Rawhide was broken. It did a directory -> file replacement improperly which causes rpm to choke. Moreover, the transition wasn't even necessary because the directory was completely unused and had been for a while.
All I did was synchronize what upstream offered, and made a small tweak based on the feedback in the PR.
Even on a week day, due to timezones and people having things like getting the Beta done, I would expect you to wait a good 48 hours after posting to the list, and if done on a weekend 48 hours of working time to ensure review and response before just pushing it anyway.
What's more you should at LEAST just push it to rawhide first and let it bake there for some time before then shoving it out to every release!
- Fedora 30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b2e124a4a
- Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-940d3922ce
- Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c4107ac9d3
- Fedora EPEL 7:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-798356a949
- Fedora EPEL 6:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-210b4d1b32
This should give people the opportunity to test the new version and get it pushed once it's validated.
But it doesn't give rel-eng and the infrastructure teams to review your changes, and we're also in freeze which means if there's something in existing stable builds that needs to be fixed for that it's quite likely that they may have to revert it all, bump an epoch to get things working again rather than having the re-validate and entire stack.
First of all, you're blowing it way out of proportion. It's only in testing, and that's pretty much the only way anyone can really see whether it works. And like it or not, it has to make its way into stable releases at some point, so that all the stuff can use it.
No, I've not.
I disabled autopushing precisely so that there's no accidental pushing to stable updates. The worst thing that can happen is that we have to unpush the update from testing. Seriously, that's really not the end of the world.
Nowhere did I say that releng needs to deploy this RIGHT NOW. Having this in rawhide and F30 updates-testing makes it possible for the dependency map for Python 2 to cleanup even more, allowing the Python SIG to continue its work to clean out Python 2 subpackages in Fedora 30/31.
So if you've disabled/removed python2 support in Fedora 30 you've broken image building at least.
PLEASE do not do this sort of stuff, it's not helpful or kind to the teams that have to deal with the infra and releases. There's no rush to get it out, it should go through the process of the maintainers reviewing your changes, it being tested in rawhide and then eventually making it to a stable release. Why did you do this? People have asked you explicitly not to do this stuff in the past yet you keep ignoring it.
Actually, for your information, this is literally the first time I've done this for infrastructure. No one has ever said anything like that to me before. I'm going to leave it at this, because if I say more, I'll probably be a lot less charitable.
I've asked you in the past, as have others.
On Mon, Mar 11, 2019 at 9:44 AM Peter Robinson pbrobinson@gmail.com wrote:
I disabled autopushing precisely so that there's no accidental pushing to stable updates. The worst thing that can happen is that we have to unpush the update from testing. Seriously, that's really not the end of the world.
Nowhere did I say that releng needs to deploy this RIGHT NOW. Having this in rawhide and F30 updates-testing makes it possible for the dependency map for Python 2 to cleanup even more, allowing the Python SIG to continue its work to clean out Python 2 subpackages in Fedora 30/31.
So if you've disabled/removed python2 support in Fedora 30 you've broken image building at least.
I double-checked this and you're sadly right. I've fixed this so koji-builder is now using Python 2 again.
I thought I had validated all the dependencies for Koji we use in infra to have been ported, but alas, imgfac hasn't been done yet.
Sorry all. I've learned my lesson. I'm not going to touch infrastructure in Fedora directly again.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 3/11/19 7:31 AM, Neal Gompa wrote:
I double-checked this and you're sadly right. I've fixed this so koji-builder is now using Python 2 again.
I thought I had validated all the dependencies for Koji we use in infra to have been ported, but alas, imgfac hasn't been done yet.
Sorry all. I've learned my lesson. I'm not going to touch infrastructure in Fedora directly again.
Well, I appreciate the work... this was something on my list (to move newer koji to python3 or try to). I also would have liked a bit more time before merging the PR (I did see it saturday night but when I got up sunday and looked it was already merged :)
These changes take time and many eyes...
kevin
On Mon, Mar 11, 2019 at 8:32 AM Neal Gompa ngompa13@gmail.com wrote:
Sorry all. I've learned my lesson. I'm not going to touch infrastructure in Fedora directly again.
It sounds like you were being careful (disabling autokarma) and this was just a corner-case. Your work on Koji and infrastructure is important, and this was an honest mistake. I make mistakes all the time.
Hopefully you continue to make contributions, because more we need more people working on these things.
- Ken
infrastructure@lists.fedoraproject.org
-
Ken Dreyer -
Kevin Fenzi -
Neal Gompa -
Peter Robinson -
Stephen John Smoogen