For long-term (low-traffic) projects, it is very useful to build package once (against fedora-rawhide) and let it live years without touching. This is how regular package maintenance works in Fedora (build once, and manually rebuild only once FTBFS occurs). Please add Fedora Rawhide back, or somehow guarantee that Fedora 27 will automatically inherit builds from Fedora 26.
(In reply to Pavel Raiskup from comment #0) > For long-term (low-traffic) projects, it is very useful to build package > once (against fedora-rawhide) and let it live years without touching. This > is how regular package maintenance works in Fedora (build once, and manually > rebuild only once FTBFS occurs). > > Please add Fedora Rawhide back, or somehow guarantee that Fedora 27 will > automatically inherit builds from Fedora 26. There might be a button f26->f27 effectively doing copy of the latest successful builds from f26 into f27 chroot as a simple solution for a start. You can also rebuild all your packages for the new chroot with the prev chroot added to 'additional repositories' so that they can be built in any order. You can also use custom chroots (now that they are enabled) configured for rawhide repos. This has been already proposed on copr-devel mailing list. Could you explain how this issue blocks 1400943 if we strive for particular chroot independent system?
(In reply to clime from comment #2) > (In reply to Pavel Raiskup from comment #0) > > For long-term (low-traffic) projects, it is very useful to build package > > once (against fedora-rawhide) and let it live years without touching. This > > is how regular package maintenance works in Fedora (build once, and manually > > rebuild only once FTBFS occurs). > > > > Please add Fedora Rawhide back, or somehow guarantee that Fedora 27 will > > automatically inherit builds from Fedora 26. > > There might be a button f26->f27 effectively doing copy of the latest > successful builds from f26 into f27 chroot as a simple solution for a start. Thanks, that's needed! > You can also rebuild all your packages for the new chroot with the prev > chroot added to 'additional repositories' so that they can be built in any > order. That would be unnecessary wasting of maintainers' time and copr's power. Unless there's a bug in package, we shouldn't make copr users rebuilding twice a year (we just should give them the option). > You can also use custom chroots (now that they are enabled) configured for > rawhide repos. This has been already proposed on copr-devel mailing list. Custom-1-* chroot is not replacement for fedora-rawhide-* in the 'maintainer -> copr -> users' pipeline. > Could you explain how this issue blocks 1400943 if we strive for > particular chroot independent system? Can you elaborate this question? Bug 1400943 is just about me to test that rawhide_to_relese script works ... because I need to maintain that. Fedora-rawhide-chroot is something which works for Fedora many years and I'm not going to disable that for internal Copr because that is terribly counter-intuitive. That reminds me that I should properly document this. The relation with this bug is: It is likely that rawhide_to_relese will get dropped because it is not needed anymore upstream (upstream will likely invent release_to_release+1 script, which is release_to_rawhide) to fix the regression.
(In reply to Pavel Raiskup from comment #3) > (In reply to clime from comment #2) > > (In reply to Pavel Raiskup from comment #0) > > > For long-term (low-traffic) projects, it is very useful to build package > > > once (against fedora-rawhide) and let it live years without touching. This > > > is how regular package maintenance works in Fedora (build once, and manually > > > rebuild only once FTBFS occurs). > > > > > > Please add Fedora Rawhide back, or somehow guarantee that Fedora 27 will > > > automatically inherit builds from Fedora 26. > > > > There might be a button f26->f27 effectively doing copy of the latest > > successful builds from f26 into f27 chroot as a simple solution for a start. > > Thanks, that's needed! > > > You can also rebuild all your packages for the new chroot with the prev > > chroot added to 'additional repositories' so that they can be built in any > > order. > > That would be unnecessary wasting of maintainers' time and copr's power. > Unless there's a bug in package, we shouldn't make copr users rebuilding > twice a year (we just should give them the option). > > > You can also use custom chroots (now that they are enabled) configured for > > rawhide repos. This has been already proposed on copr-devel mailing list. > > Custom-1-* chroot is not replacement for fedora-rawhide-* in the > 'maintainer -> copr -> users' pipeline. > > > Could you explain how this issue blocks 1400943 if we strive for > > particular chroot independent system? > > Can you elaborate this question? Bug 1400943 is just about me to test > that rawhide_to_relese script works ... because I need to maintain that. > Fedora-rawhide-chroot is something which works for Fedora many years and > I'm not going to disable that for internal Copr because that is terribly > counter-intuitive. That reminds me that I should properly document this. > > The relation with this bug is: It to me is likely that rawhide_to_relese will > get dropped because it is not needed anymore upstream (upstream will > likely invent release_to_release+1 script, which is release_to_rawhide) > to fix the regression. Rawhide_to_Release might get generalized to allow moving builds between any two chroots and it might become function available to users from UI named something like 'Fork chroot'. This function will be able to achieve the same result the rawhide_to_release command. You can add fedora-rawhide in your test and test on it. That's why this feature request does not block 1400943 in any way.
(In reply to clime from comment #4) > Rawhide_to_Release might get generalized to allow moving builds between any > two chroots and it might become function available to users from UI named > something like 'Fork chroot'. > > This function will be able to achieve the same result the rawhide_to_release > command. Agreed, that would be neat. > You can add fedora-rawhide in your test and test on it. That's why this > feature request does not block 1400943 in any way. Ah, I now understand your question -- that's just the result of "Bug clone" action; and the blocks field doesn't break any process. Fixing anyway.
In the end, I think we should have "rawhide" when mock has config for rawhide chroot that uses rawhide repos specifically. Having named it after release is interesting but, for sure, might be complicated to think about. And the described features, if they will be implemented, are not dependant on particular chroot naming. New Copr version has been released.