copr-dist-git branch naming and mock names

[Pavel Raiskup]

So far in Copr, there is  "inherited" git branch naming from Fedora's
dist-git, i.e.  'f24' for fedora 24, el5 for 'epel-5' and epel7 for
'epel-7'.  The chroots in Fedora Copr are named 'fedora-N-ARCH' or
'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6,
shouldn't there be mag6?).  But Copr is not supposed to be used by Fedora
only.

The problem I internally solved/workaround-ed are RHEL chroots.  Those are
named 'rhel-VERSION-ARCH'.  To have it done there are several patches
(against dist-git, backend, and front-end packages).

The problem, for example is, that 'el6' branch is "by default"
allocated
for 'epel-6-ARCH' chroots, and can not be used by RHEL.  There are
multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).

I'm curious whether we could "rename" the existing branches to some more
consistent, "future-friendly" strings.  For example:

-> 'fedora/25'      (the actual f25)
-> 'fedora/rawhide' (the actual master)
-> 'centos/7'       (the actual epel7)
-> 'centos/6'       (the actual el6)
-> 'mageia/6'       (the actual mga6)
-> 'epel/7'         (doesn't exist yet ..)
-> 'rhel/version'   (exists internally ..)

For OCD like me, it would be really pretty having it "cleanly" named, but
it would be also useful for 'chroot-id <-> branch-name <-> dist-tag'
converting (which now requires downstream _code_ patching, not only
configuration).

Also, if we used such naming, there's no need to think again what the
'master'
branch is used for ... (rhel? fedora? epel?) and for the future, adding
other distributions (or complements for say rpmfusion) would be easy.

I don't remember why I chose 'fedora/25' "downstream" instead of
'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I
prefer '/' separator.  But that basically doesn't matter.

Anyway --> is something like that acceptable upstream?  I have patches for
it already (this would require copying branches within existing git
repositories).  There is plan B:  propose this patches but add options
turning this behavior on/off, whatever default we'll choose.

While we are on that, could we discuss renaming from 'epel-*' to
'centos-*'?  Because we don't tell the truth entirely if we claim those are
epel-* chroots.

Pavel

[Michal Novotny]

I think that only real restriction on branch naming is in fedpkg/fedpk-copr
(load_rpmdefines function).
I think that's the heart of the issue. If you could provide a sane default
case for parsing branch_merge variable,
then we could adjust everything else (e.g. mock_chroot_name -> branch,
branch -> os
conversions in frontend or dist-git.conf if needed).

clime

On Wed, Sep 21, 2016 at 4:59 PM, Pavel Raiskup <praiskup(a)redhat.com&gt; wrote:

>  So far in Copr, there is  "inherited" git branch naming
> from Fedora's
>  dist-git, i.e.  'f24' for fedora 24, el5 for 'epel-5' and epel7 for
>  'epel-7'.  The chroots in Fedora Copr are named 'fedora-N-ARCH' or
>  'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6,
>  shouldn't there be mag6?).  But Copr is not supposed to be used by Fedora
>  only.
>
>  The problem I internally solved/workaround-ed are RHEL chroots.  Those are
>  named 'rhel-VERSION-ARCH'.  To have it done there are several patches
>  (against dist-git, backend, and front-end packages).
>
>  The problem, for example is, that 'el6' branch is "by default"
> allocated
>  for 'epel-6-ARCH' chroots, and can not be used by RHEL.  There are
>  multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).
>
>  I'm curious whether we could "rename" the existing branches to some more
>  consistent, "future-friendly" strings.  For example:
>
>  -> 'fedora/25'      (the actual f25)
>  -> 'fedora/rawhide' (the actual master)
>  -> 'centos/7'       (the actual epel7)
>  -> 'centos/6'       (the actual el6)
>  -> 'mageia/6'       (the actual mga6)
>  -> 'epel/7'         (doesn't exist yet ..)
>  -> 'rhel/version'   (exists internally ..)
>
>  For OCD like me, it would be really pretty having it "cleanly" named, but
>  it would be also useful for 'chroot-id <-> branch-name <-> dist-tag'
>  converting (which now requires downstream _code_ patching, not only
>  configuration).
>
>  Also, if we used such naming, there's no need to think again what the
>  'master'
>  branch is used for ... (rhel? fedora? epel?) and for the future, adding
>  other distributions (or complements for say rpmfusion) would be easy.
>
>  I don't remember why I chose 'fedora/25' "downstream" instead of
>  'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I
>  prefer '/' separator.  But that basically doesn't matter.
>
>  Anyway --> is something like that acceptable upstream?  I have patches for
>  it already (this would require copying branches within existing git
>  repositories).  There is plan B:  propose this patches but add options
>  turning this behavior on/off, whatever default we'll choose.
>
>  While we are on that, could we discuss renaming from 'epel-*' to
>  'centos-*'?  Because we don't tell the truth entirely if we claim those are
>  epel-* chroots.
>
>  Pavel
>  _______________________________________________
>  copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org
>

[Pavel Raiskup]

Top-post did not help anybody here .. I don't think I called about restrictions.
I have a feeling that there will be new branches in future and even now it is
not really tidy.  But to be honest, I don't understand your answer, are we able
to change the branch naming?  And mock naming?

Pavel

On Thursday, September 22, 2016 8:04:24 AM CEST Michal Novotny wrote:
>  I think that only real restriction on branch naming is in
> fedpkg/fedpk-copr
>  (load_rpmdefines function).
>  I think that's the heart of the issue. If you could provide a sane default
>  case for parsing branch_merge variable,
>  then we could adjust everything else (e.g. mock_chroot_name -> branch,
>  branch -> os
>  conversions in frontend or dist-git.conf if needed).

[Jean-Marc Liger]

Le 21/09/2016 à 16:59, Pavel Raiskup a écrit :
>  So far in Copr, there is  "inherited" git branch naming
> from Fedora's
>  dist-git, i.e.  'f24' for fedora 24, el5 for 'epel-5' and epel7 for
>  'epel-7'.  The chroots in Fedora Copr are named 'fedora-N-ARCH' or
>  'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6,
>  shouldn't there be mag6?).  But Copr is not supposed to be used by Fedora
>  only.
>
>  The problem I internally solved/workaround-ed are RHEL chroots.  Those are
>  named 'rhel-VERSION-ARCH'.  To have it done there are several patches
>  (against dist-git, backend, and front-end packages).
>
>  The problem, for example is, that 'el6' branch is "by default"
> allocated
>  for 'epel-6-ARCH' chroots, and can not be used by RHEL.  There are
>  multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).
>
>  I'm curious whether we could "rename" the existing branches to some more
>  consistent, "future-friendly" strings.  For example:
>
>  -> 'fedora/25'      (the actual f25)
>  -> 'fedora/rawhide' (the actual master)
>  -> 'centos/7'       (the actual epel7)
>  -> 'centos/6'       (the actual el6)
>  -> 'mageia/6'       (the actual mga6)
>  -> 'epel/7'         (doesn't exist yet ..)
>  -> 'rhel/version'   (exists internally ..)
>
>  For OCD like me, it would be really pretty having it "cleanly" named, but
>  it would be also useful for 'chroot-id <-> branch-name <-> dist-tag'
>  converting (which now requires downstream _code_ patching, not only
>  configuration).
>
>  Also, if we used such naming, there's no need to think again what the
> 'master'
>  branch is used for ... (rhel? fedora? epel?) and for the future, adding
>  other distributions (or complements for say rpmfusion) would be easy.
>
>  I don't remember why I chose 'fedora/25' "downstream" instead of
>  'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I
>  prefer '/' separator.  But that basically doesn't matter.
>
>  Anyway --> is something like that acceptable upstream?  I have patches for
>  it already (this would require copying branches within existing git
>  repositories).  There is plan B:  propose this patches but add options
>  turning this behavior on/off, whatever default we'll choose.
>
>  While we are on that, could we discuss renaming from 'epel-*' to
>  'centos-*'?  Because we don't tell the truth entirely if we claim those are
>  epel-* chroots. 
To be completeness,  you have both centos and epel repositories enabled, 
with centos dist tag.

Jean-Marc

>  Pavel
>  _______________________________________________
>  copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org

[Pavel Raiskup]

On Thursday, September 22, 2016 9:39:34 AM CEST Jean-Marc Liger wrote:
>  > While we are on that, could we discuss renaming from
> 'epel-*' to
>  > 'centos-*'?  Because we don't tell the truth entirely if we claim those
>  > are epel-* chroots.
>  
>  To be completeness,  you have both centos and epel repositories enabled, 
>  with centos dist tag. 
Yup.  That's valid argument (to some extent) to have it still named 'epel-*',
thanks!

The thing is that I already have (as a copr user, not maintainer, and not yet
resolved) issues with the fact that there are different packages from those in
Koji's `epel-*` ..  So the epel in copr is not the same epel as in koji.

I'm not sure what to do with this, could Copr finally use the same repos as
Koji uses?

Pavel

[Miroslav Suchý]

Dne 21.9.2016 v 16:59 Pavel Raiskup napsal(a):
>  Anyway --> is something like that acceptable upstream?  I have
> patches for
>  it already (this would require copying branches within existing git
>  repositories).  There is plan B:  propose this patches but add options
>  turning this behavior on/off, whatever default we'll choose. 
Patches against what? This originate in fedpkg and fedora dist-git.
Copr-dist-git and copr-fedpkg already has some difference, but I do not want to differ
even more.
Imho this should be discussed with Fedora-infra and maintainer of fedpkg.

>  While we are on that, could we discuss renaming from 'epel-*'
> to
>  'centos-*'?  Because we don't tell the truth entirely if we claim those are
>  epel-* chroots. 
??? Epel chroot does not mean RHEL. It means EPEL, which is "high quality set of
additional packages for Enterprise
Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and
Scientific Linux (SL), Oracle Linux
(OL). "

On the other hand, the name "centos-*" would imply that it is just CentOS,
without additional repos. Which is not true.
It may have sense if we add "centos-*" beside the "epel-*", but there
is no demand for that. And it will likely just
confuse people.


-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

[Pavel Raiskup]

On Friday, September 23, 2016 11:03:27 AM CEST Miroslav Suchý wrote:
>  Dne 21.9.2016 v 16:59 Pavel Raiskup napsal(a):
>  > Anyway --> is something like that acceptable upstream?  I have patches for
>  > it already (this would require copying branches within existing git
>  > repositories).  There is plan B:  propose this patches but add options
>  > turning this behavior on/off, whatever default we'll choose.
>  
>  Patches against what? 
Against everything which is needed to be patched.  I was OK with patching Copr
only to fix internal Copr instance.

>  This originate in fedpkg and fedora dist-git.  Copr-dist-git and
> copr-fedpkg
>  already has some difference, but I do not want to differ even more. 
Why can't we differ?  Is fedora dist-git ever going support all the repos
Copr will support?

Then maybe it is not the correct approach for Copr, because fedpkg is strictly
Fedora oriented, and Copr should not be.

The plan B is about optional feature (plan A is to make it done in Fedora
Copr similarly as is done in internal Copr).  Trust me, now you basically
enforce the branch naming for everybody who would consider using Copr.
Changing branch layout requires downstream patching and package rebuilds.

>  Imho this should be discussed with Fedora-infra and maintainer of
> fedpkg. 
I probably miss the point why this is so sensitive topic.

But I don't really plan to bother Fedora people to force them to change
branching policy.  Especially if I see how problematic is to even discuss
this for @copr.  So the answer is NO -- we'll never change that branching policy
*in copr*?  Because if we wanted to have this done, sooner is better...

>  > While we are on that, could we discuss renaming from
> 'epel-*' to
>  > 'centos-*'?  Because we don't tell the truth entirely if we claim those
>  > are epel-* chroots.
>  
>  ??? Epel chroot does not mean RHEL. It means EPEL, which is "high quality
>  set of additional packages for Enterprise Linux, including, but not limited
>  to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL),
>  Oracle Linux (OL). " 
Agreed.  Already explained in different thread.

>  On the other hand, the name "centos-*" would imply that it
> is just CentOS,
>  without additional repos. Which is not true.  It may have sense if we add
>  "centos-*" beside the "epel-*", but there is no demand for that. And
> it will
>  likely just confuse people. 
Agreed.  As written in different thread, can epel in Fedora copr be the same as
epel in Fedora's default build system?

Pavel

[Miroslav Suchý]

Dne 23.9.2016 v 12:44 Pavel Raiskup napsal(a):
>  Why can't we differ?  
Because it adds more maintenance overhead.

>  Is fedora dist-git ever going support all the repos
>  Copr will support? 
Ideally this should be config driven. And Fedora and Copr should have the same code, just
different configs.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

[Pavel Raiskup]

On Friday, September 23, 2016 1:30:41 PM CEST Miroslav Suchý wrote:
>  Dne 23.9.2016 v 12:44 Pavel Raiskup napsal(a):
>  > Why can't we differ? 
>  
>  Because it adds more maintenance overhead. 
ATM there is maintenance overhad on our side same as on your side, IIUC.  While
simple patch would solve my problems, without bothering you.  And, TBH, current
packaging of copr as-is in Fedora is not useful to anybody else than for Fedora
copr.

>  > Is fedora dist-git ever going support all the repos Copr will
> support?
>  
>  Ideally this should be config driven. 
Thats right... ideally.

>  And Fedora and Copr should have the same code, just different
> configs. 
I'm not sure what this means for me.  Can you elaborate?  Do I have to
motivate fedpkg maintainers (is anybody from Copr team in fedpkg team?) to
accept my patches to solve issue between fedora copr and redhat copr?

What I talked about is straight forward patch against your sources, I'm
just curious whether you would like to have different naming for your
branches, or whether I need to make it optional.

Pavel