On 5/30/19 1:18 PM, Neal Gompa wrote: > I'm actually okay with the thought of Koji hub moving to Fedora. I'd > rather see most of our infra running on Fedora so that we don't get > kneecapped by RHEL moving too slowly. Our transition to Python 3 was > made way more complicated by the fact our infrastructure ran on RHEL 6 > or RHEL 7, where Python 3 wasn't available in a useful manner for a > very long time. Having our own infra run on our distribution that we > have a say in makes a huge difference in being able to move things > forward. Sure, but it means more work for us due to the updates churn and upgrades/re-installs. If we do have to do this, I'm going to likely investigate just moving the hubs into openshift. > Not that I hate RHEL or anything, but we don't have a say in anything > when it comes to RHEL, and they don't really care about bugs we report > that afflict us that much. Not exactly the most solid foundation to > run a distribution's infrastructure on, wouldn't you say? Well, I don't find that to really be the case... in the past when we have needed things urgently many RHEL folks have gone out of their way to come up with a solution for us. ...snip... >> >> * This cannot land until we finish sorting out armv7 builder issues. >> (see bug https://bugzilla.redhat.com/show_bug.cgi?id=1576593 ). >> I am trying to see if we can get away with a f29 userspace and a >> specific kernel we think works. Until this is moved however, all the >> armv7 buildvm's are on fedora 27, so they wouldn't be able to handle >> this change. >> > > Ugh, I didn't realize this is still a problem. It _should_ work with > an F30 userspace on the F27 kernel, but that's gross... :( I'm not sure it does, but I can test that combo, given time. >> * The drpm issue is somewhat minor in my mind since we don't produce >> very useful drpms right now (due to pungi not having anything more than >> the last updates compose to build them against). >> > > This feels more like a failing on pungi. We don't have archives or > indexes of what old composes looked like to maintain drpm content? It's out of scope for pungi to keep track of a bunch of composes. It really only is concerned with the compose it's doing. Likely we need a higher level script/tool that keeps drpms from all the composes that makes sense available. Or perhaps we need pungi to not do drpms at all, but have something else do them out of band and update when it finishes. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
