Hello Matthias,
On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge <mrunge@xxxxxxxxxxxxxxxxx> 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.
like bumps of certain packages, branching event, and possibly others.
Thanks,
Matthias
[1] https://www.rdoproject.org/what/dlrn/
--
Matthias Runge <mrunge@xxxxxxxxxxxxxxxxx>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
