On Sun, Mar 10, 2019 at 7:12 PM Peter Robinson <pbrobinson@xxxxxxxxx> 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
