On Sun, Mar 10, 2019 at 11:42 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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. 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. _______________________________________________ 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
