Copr URLs
by Pierre-Yves Chibon
Hi all,
Something, I have been discussing with Tomas last week but not with
Slavek or the list, is the URLs we have in copr.
For example:
front page: /
detail of a copr: /coprs/detail/toshio/packagedb/
copr's permissions: /coprs/detail/toshio/packagedb/permissions/
copr's builds: /coprs/detail/toshio/packagedb/builds/
someone's copr: /coprs/owned/toshio/
I basically would like to change a couple of things. At the moment when
I'm looking at toshio's packagedb repos there is no way to (from the
url) easily go back to the list of toshio's copr.
So I would like to propose:
/ > home
/coprs/ > list all the repos (same as home, atm)
/coprs/<user>/ > list someone's copr
/coprs/<user>/<repo>/ > the detail of this copr
/coprs/<user>/<repo>/{permissions,builds,...}/ > same as now the
permissions, builds or other page for this repo (the repo file for yum
could end up here as /coprs/<user>/<repo>/repo/ )
It's something I have in mind but would like to discuss before doing
(unless someone beats me to it).
So, what do you think?
Pierre
10 years
Re: What will be COPR?
by Rex Dieter
On 08/14/2013 12:22 PM, Miroslav Suchý wrote:
> Hi,
> as I started working on COPR I gathered dozens requirements, which does
> not fit into current COPR architecture and I make little step back and
> thought about COPR and what we can have.
>
> This is current options:
>
> 1) Continue with current code.
> Pros: We can have working (and public) solution very fast (aprox. ETA +1
> month).
> Cons: It will be very simply. I will probably have very few time for
> coding RFE so implementation of all RFE will take ages
option 1.
imo, copr's is implementation looks fairly complete for it's supported
use-cases. please keep it simple.
Folks that want more, can explore their own alternatives, including koji
or obs.
-- rex
10 years, 1 month
What will be COPR?
by Miroslav Suchý
Hi,
as I started working on COPR I gathered dozens requirements, which does
not fit into current COPR architecture and I make little step back and
thought about COPR and what we can have.
This is current options:
1) Continue with current code.
Pros: We can have working (and public) solution very fast (aprox. ETA +1
month).
Cons: It will be very simply. I will probably have very few time for
coding RFE so implementation of all RFE will take ages (well years
probably). Very young code (with all its implication).
2) Merge current code with Koji as backend
Pros: We will use mature code of Koji
Cons: It will be even more time consuming than option 1. So it will
probably mean start with option 1) and then during several months (I
estimate it to year or even more) get needed changes in Koji and glue it
together with COPR. Therefore even less time for RFE.
3) Use Open Build Service
Pros: Mature code with already big community. Can be set up relatively
quick (ETA 5 months). Lots of feature that neither Koji have.
Cons: different workflow and tools than we are all used to. It does not
have some features which Koji have.
Obviously there is no right choice. Each option have its pros and cons.
I would love to hear which option you do prefer.
--
Miroslav Suchy,
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
10 years, 1 month
copr is now functional again
by Miroslav Suchý
We had some problems with Copr beckend. It was not responsive and Kevin
had to reprovision it and then it does not pick up jobs.
It take several days, but now COPR should be fully operational again.
And F19 is imported.
--
Miroslav Suchy
Red Hat, Software Engineer
10 years, 1 month
