copr-dist-git branch naming and mock names
by 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
7 years, 2 months
Having FE design/templates "pluggable"
by Pavel Raiskup
For better orientation, internally we have "red color" design for copr frontend
(so users immediately know where they are).
It would be really useful if paths to template files were configurable via FE
configuration file .. so non-Fedora instances could simply "just" edit
config, instead of downstream-patch many template files.
Ideally, even the alternative design(s) should be "upstreamable" .. so we
could e.g. submit patch adding alternative design. But admin's should be
able to provide alternative 'copr-frontend-design-XXX' packages.
WDYT? Would be patches implementing this idea accepted?
Pavel
7 years, 2 months
Fwd: [Bug 1376844] New: Please start using processes like
code-review, etc.
by Miroslav Suchý
This is not really bug. So I will close it in BZ. But I'm happy to discuss it here.
I disagree that we need code review before push. This is quite small project, with only few active developers.
Although you can find some commits which can be discussed, most of them are straight.
If you want to do review, then you can subscribe to:
https://lists.fedorahosted.org/admin/lists/copr-commits.lists.fedorahoste...
And comment the commit here on this mailing list. If needed, it can be rejected.
Mirek
-------- Přeposlaná zpráva --------
Předmět: [Bug 1376844] New: Please start using processes like code-review, etc.
Datum: Fri, 16 Sep 2016 14:53:30 +0000
Od: bugzilla(a)redhat.com
Komu: msuchy(a)redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1376844
Bug ID: 1376844
Summary: Please start using processes like code-review, etc.
Product: Copr
Component: backend
Assignee: msuchy(a)redhat.com
Reporter: praiskup(a)redhat.com
Copr is starting to be very popular and key part of Fedora's and Red Hat's
infrastructure, and it deserves proper processes. I'm not talking about hard
bureaucracy, but some clear 'Pull-request -> code-review -> push' is enough.
If there is done something like that in background (I strongly believe there
is) please open that process.
I'd be glad to be part of the review process if there is something really
design breaking.
Copr really needs new consumer, that is important point, so please:
- let's not hard-wire anything specific to Fedora instance copr
- if there is something Fedora-instance specific, make it optional, pluggable
thing
--
You are receiving this mail because:
You are the assignee for the bug.
7 years, 2 months
Mageia chroots enabled
by Michal Novotny
Hello all,
we have just enabled Mageia-6 and Mageia-x86_64 chroots for i586 + x86_64
archs. So if you want to build something for Mageia (https://www.mageia.org/),
please, feel free to try.
Best Regards
COPR team
7 years, 2 months
Docker requirement
by Pavel Raiskup
Hi all,
this is probably proper place for such discussions -- I am curious what is the
plan with Docker stuff within Copr project.
Do you plan to make Fedora's copr hardly dependant on Docker images?
Do you plan to have anything Docker-related optional? Or are other ways to
deploy things planned to be obsoleted?
Thanks,
Pavel
7 years, 2 months
Clime as primary maintainer of Copr service
by Miroslav Suchý
Hi,
I want to announce that Clime (Michal N.) is now primary maintainer of Copr service.
I will focus on gathering requirements from other teams around Fedora and introducing new features.
And Clime will manage day-to-day operations - making sure that Copr is up and running.
He is doing that job already better than me.
I am still around, but do not hesitate to contact Clime with any issue of Copr.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
7 years, 2 months
New COPR version deployed
by Michal Novotny
Hello,
a new version of COPR packages were deployed to their respective machines.
The most prominent changes are:
- pyp2rpm, tito, gem2rpm tools now generate their SRPMs in isolation from
the host system (security and in-future perhaps resource limiting
measurement)
- sketch of modularity introduced (please, see
https://www.youtube.com/watch?v=uNW8QEzsdDg about how to use it)
- mock build configs are now available in the result directories (under
./configs)
- few bugfixes
Enjoy
COPR team
7 years, 2 months
