copr-devel August 2013

copr-devel@lists.stg.fedorahosted.org

3 participants
4 discussions

Copr URLs
by Pierre-Yves Chibon 13 Sep '13

13 Sep '13

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

4 9

Re: What will be COPR?
by Rex Dieter 14 Aug '13

14 Aug '13

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

2 1

What will be COPR?
by Miroslav Suchý 14 Aug '13

14 Aug '13

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

1 0

copr is now functional again
by Miroslav Suchý 07 Aug '13

07 Aug '13

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel August 2013