On Thu, Jan 31, 2019 at 11:16 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > https://pagure.io/fesco/issue/2068 > > > > And, after all, those packages shouldn’t be shipped to users. > > This of course means however that users who want to build their own > verions of the applications or whatever can't start from our repos, they > have to use whatever setup we use for developing them. I don't know any > answers here but it seems to me we keep making it harder for people to > use Fedora to develop applications. All packages built in MBI are meant to be eventually contributed back to Fedora. Just like developing a package on your own system and building in local mock. Eventually you push the code to dist-git and rebuild packages in Fedora Koji. With MBI the difference is that people can collaboratively devlop changes and they have scalable build infrastructure. > > Separate Koji + Koschei deployed in Fedora infrastructure cloud; > > Turns out we are going to be retiring our cloud, so no, this is not a > place to put it. :) Cloud doesn't necessarily mean OpenStack. There are other options. For example, a baremetal, out-of-warranty virthost in an isolated network would work - better that OpenStack. MBI was ran this way (baremetal server with KVM guests) for some time. But it was a private setup, usably only by a few people. Among other things it was used for GCC removal from buildroot change - all packages were mass-rebuilt several times and then build logs were scanned to see which packages failed due to missing gcc/g++ and would need to have BuildRequires added. The change was eventually pushed to Fedora. > > People can have their own targets where they can break things as they > > wish without affecting others; > > Would that be entirely self service? Or ? No, I would be setting up these tags/targets myself, manually. > > Package changes are eventually contributed to Fedora proper by merging > > changes to Fedora dist-git and rebuilding packages in official Fedora Koji; > > Where is the source for the changes from? Would this need it's own > pagure/src/dist-git? Or would it pull from PR's in prod dist git? Or ? Changes would be kept somewhere, depending on packager preferences. Ideally in a publicly-available git repository where people can collaborate. Ideally in a fork on src.fedoraproject.org to make sure that contributors have FPCA signed. Giving myself as example, I have forked all my packages and created "mbi" branches for them, for example: https://src.fedoraproject.org/fork/mizdebsk/rpms/ant/commits/mbi > > Idea №3: Building packages for multiple distributions > > > > In Rust ecosystem, we managed to get have same packaging guidelines in > > openSUSE, Mageia and Fedora. We could automatically build some packages on > > multiple distributions and be kinda upstream. > > So, this setup will need to distribute things... would it need mirrors > as well? or ? Nothing is distributed to end users. This system is for use by Fedora contributors - packagers/QA/etc. Of course anyone interested is able to download these packages, but they are not meant for end users. Just like Koji scratch builds are not meant for end users, but anyone can download them and use in production, if they like. > > A few builders constantly running, with a possibility to add more > > builders as needed and as available cloud resources allow > > koji doesn't have much way to dynamically deal with builders... Koji builders can be added and removed dynamically very easily. Adding a builder in public cloud is as easy as spawning some VM, installing koji-builder, putting config file in place and starting kojid - of course automated using Ansible. Removing a builder only requires terminating the VM, nothing more. Adding a builder that is installed on your laptop is as easy as booting up the VM containing in, that's it. > > Possibility to have some builders running outsides of Fedora > > infrastructure - contributed by proposal owners > > I'd be carefull of this, as it can cause a lot of issues, but of course > up to you as you are doing the work. :) The idea was to have just a few builders (eg. 3) running constantly. If someone wants to do massive amounts of builds (and have them complete quickly) then they can plug in their own hardware or instances in public cloud that they would pay for, which would be added to a separate Koji channel. Then their builds would use their builders. Builders have very low requirements - in particular they don't need public IP, can be behind firewall/NAT and only need to talk to hub over https. Even someone's personal laptop could be used as a builder. > > Koji builds can be done from SCM (src.fp.o, pagure.io, github, …) or > > from SRPM upload > > Ah, so it would not have it's own git/pagure? No. Builds would be allowed from any configured SCM - it could be from forks on src.fedoraproject.org, from repositories on pagure.io, repositories on other git hosting services. It's up to people using the system to choose the workflow that suits them best. They could even build from SRPM uploads. > > It is not official build system of Fedora which is not helping with Problem > > №2: Testing of new rpm/koji/mock features/configuration > > <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGgqJ_Y/edit#heading=h.iodoq4xw80c2> > > Note that if you also are testing new things you could break packagers > that are trying to do other work... Testing new features would be done in separate tags. So no, others would not be affected. > > By building only on a single, fast architecture. > > This may well bite you when you merge back to koji and build for all > arches. I don't see this as a problem.Most of the packages that we are planning to build in MBI (Java/Rust/Go) are noarch anyway. > Overall sounds very nice... we will have to work out details if everyone > is on board with it. Do note that it's going to be a lot of work for you > all... :) Actually there's not that much work. Most of the work is already done. I've developed and I'm running MBI setup myself in AWS, using my personal account. Others liked this workflow and asked whether they could use it. I kindly refused as I can't pay for all that myself. Then we come up with a proposal to have this hosted by Fedora. -- Mikolaj _______________________________________________ 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
