Hide Forgot
Description of problem: Maybe it is better not to have a Rawhide branches in Copr at all and always just call the newest chroot fedora-(latest_branch+1)? (ie currently would be fedora-26): (koji does this in terms of tagging and %dist, right?) Anyway the current behaviour of copr for new Fedora branches (ie current F25) seems unintuitive and a little annoying. First we need to add the new (old?) chroots and then build for it, even though the 'rawhide' repo already has the appropriate builds. So it seems better to me to call current rawhide "F26" in Copr and then when it branches add a new "F27" to copr which would be required to be added and built for (instead of having "Rawhide"). Otherwise for unmaintained coprs you also get this funny gap with an old out-of-date rawhide copr and then say a f23 copr with nothing in between which makes little sense: with my suggestion also easy to see quickly if a copr is actively maintained. Steps to Reproduce: 1. after Fedora branches Actual results: many coprs don't have F25 Expected results: better to create f26 in copr after f25 branched: ie create newer repos rather than old branched repo.
Fixed by https://github.com/fedora-copr/copr/commit/9ef053b3 and https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=05018f93.
Worth saying this is actually discussed at: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org/thread/W4AE6EQBXVGQ4MH7MJ5JLW43OZKKHPNH/
(In reply to clime from comment #1) > Fixed by https://github.com/fedora-copr/copr/commit/9ef053b3 and What is going to happen with this migration at F28 time? It means that I no longer can use migration scripts from upstream in internal copr, because I'm deploying with "slight" delay :(. > https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/ > ?id=05018f93. This is wrong too. You'll have to fix the script all the time with increasing fedora number.
(In reply to Jens Petersen from comment #0) > Description of problem: > Maybe it is better not to have a Rawhide branches in Copr at all and > always just call the newest chroot fedora-(latest_branch+1)? (ie > currently would be fedora-26): (koji does this in terms of tagging and > %dist, right?) NO, please. At least if I'm not missing something important. > Anyway the current behaviour of copr for new Fedora branches (ie current > F25) seems unintuitive and a little annoying. First we need to add the > new (old?) chroots and then build for it, even though the 'rawhide' repo > already has the appropriate builds. Once copr repo has `fedora-rawhide-x86_64`, moving to f26 could be pretty much automatized process across all copr repositories, similarly to Fedora branching. If anybody was against this, it can be opt-out feature of course. To be honest, something like this happened for coprs I maintain at least once, but I'm not sure what's wrong with the automatic process. > So it seems better to me to call current rawhide "F26" in Copr and then > when it branches add a new "F27" to copr which would be required to be > added and built for (instead of having "Rawhide"). Otherwise for > unmaintained coprs you also get this funny gap with an old out-of-date > rawhide copr and then say a f23 copr with nothing in between which makes > little sense: with my suggestion also easy to see quickly if a copr is > actively maintained. It doesn't look like a better approach, because people moving to newer Fedoras, for example, will have broken links anyway ($releasever is incremented and the repo doesn't exist). And you effectively disable Copr for Rawhide users, there is no automatic move from $releasever == 'rawhide'. Unmaintained coprs are still unmaintained coprs. Worth pinging maintainer, making sure you consume up2date software. As I understand your request, Copr should keep `rawhide` builds in `fedora-rawhide-*` and create `f26` (in future, not now, at branching time) and e.g. hardlink built packages from `fedora-rawhide-x86_64` into `fedora-26-x86_64` repository at that time. Automatically, right? So people maintaining copr repositories don't have to do this manually.
(In reply to Pavel Raiskup from comment #3) > > https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/ > > ?id=05018f93. > > This is wrong too. You'll have to fix the script all the time with > increasing > fedora number. What about having `fedora-26-*` symlinks distributed through mock, if this is useful for somebody ...?
For internal Copr important PR: https://github.com/fedora-copr/copr/pull/21
> As I understand your request, Copr should keep `rawhide` builds in > `fedora-rawhide-*` and create `f26` (in future, not now, at branching > time) and e.g. hardlink built packages from `fedora-rawhide-x86_64` into > `fedora-26-x86_64` repository at that time. Automatically, right? So > people maintaining copr repositories don't have to do this manually. This looks like the sane approach to me. The original proposal is still better than the status quo, but automatic branching as in Koji is really the right way to handle this.
(In reply to Kevin Kofler from comment #7) > This looks like the sane approach to me. The original proposal is still > better than the status quo, but automatic branching as in Koji is really the > right way to handle this. This is new for me, but that's implemented in Copr already (admin can run `./manage.py rawhide_to_release A B` at the time of fedora branching). Admins should consider running this for F25 asap.