Hello Matthias,

On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge <mrunge@matthias-runge.de> wrote:
On Tue, Aug 22, 2017 at 05:17:56AM +0200, Michal Novotny wrote:
> Hello,
>
> we will have soon a planning meeting that should determine a more long-term
> strategy and bring us to a team agreement on what COPR currently is and
> what it should be in half a year or so.
>
> I would like to kindly ask for some input here on the devel list to find
> out what the actual expectations of COPR are and if there are any ideas
> about what could COPR bring to the game.

So, as a starter, what I really like about copr is:

- it is actually a incubator, a tool to get packages or collections of
  packages built. One can easily experiment without actually disturbing
  other users. Copr lowers the entry barrier for new pacakgers.

- the ability to directly upload srpms; that is, one can store spec
  files etc. on the local machine. I'm undecided, if integrating a
  distgit on copr would solve any issues or would introduce more, like
  diverging specs.

- the ability to include external repositories, like the one from CentOS
  project.


Thanks! Good to hear what features are appreciated.

 
What I would like to see:

- maybe a easy possibility to build packages triggered by upstream
  source changes. This is comparable to delorean[1]. I'm not sure if it
  needs to be re-implemented.

We actually have this possibility implemented through SCM-1 and SCM-2
source types and webhook mechanism.
 
- prioritization of manually uploaded tasks vs. automatic builds. If
  that really lowers the waiting time for builds it to be discussed.
  Maybe adding a "bulk" flag to tag builds as: build it, when a builder
  is available, but it's not a priority. Send a message once the build
  is done.

We have added --background tag which is very similar to --bulk tag you
are suggesting. It's a user option (choice) to tag a build like this if he or she
wants to.
 

- it would be great, if there is a possibility to trigger rebuilds on
  dependent packages, like rebuild required packages after ABI bump.

Right, this would be a nice option. I could imagine this being implemented
as a configurable fedmsg listener that would launch rebuilds on certain events
like bumps of certain packages, branching event, and possibly others.
 


Thanks,
Matthias

[1] https://www.rdoproject.org/what/dlrn/
--
Matthias Runge <mrunge@matthias-runge.de>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org