Hello Matthias, On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge <mru...@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 <mru...@matthias-runge.de> > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
