Bug 1381790

Summary: rename Rawhide to F26 in Copr and create F27 when Fedora branches instead
Product: [Community] Copr Reporter: Jens Petersen <petersen>
Component: backendAssignee: clime
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: clime, praiskup
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-11 13:04:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jens Petersen 2016-10-05 04:02:49 UTC
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.

Comment 3 Pavel Raiskup 2016-10-11 04:15:05 UTC
(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.

Comment 4 Pavel Raiskup 2016-10-11 04:35:08 UTC
(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.

Comment 5 Pavel Raiskup 2016-10-11 04:39:07 UTC
(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 ...?

Comment 6 Pavel Raiskup 2016-10-11 06:59:11 UTC
For internal Copr important PR:
https://github.com/fedora-copr/copr/pull/21

Comment 7 Kevin Kofler 2016-10-12 01:50:17 UTC
> 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.

Comment 8 Pavel Raiskup 2016-10-13 10:10:38 UTC
(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.