Hello Gerd,
On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
Hi,
> It's easier on implementation. That's the main reason. I generally
> believe that
> what's easier on implementation is better.
It's maybe easier on the copr side, but not for the copr users ...
If you can modify the upstream project (either because you are
upstream, or in case upstream is willing to accept patches for copr
support) you can just use tito and be done with it.
If you can't modify upstream it starts to become difficult ...
So, what would be really helpful, especially for CI with the option to
build and test every upstream commit, would be support for *two* git
repos. One git repo where the spec-file and other build-related stuff
lives (distgit like). One git repo where the unmodified upstream
source lives. Updates on either repo triggers a build. The build runs
"git archive" on the upstream repo to generate the tarball and tweaks
the specfile (Source and Release tags probably) before kicking off mock
for the actual build.
Right, this is cool. The problem is that the upstream repo would need
to be configured to provide a public message that something has been changed
in it (i.e. new release) so the question is how to do this part. All the rest
we could probly do with rpkg and a particular downstream repo setup.
For Pagure it would be easy because there are fedmsgs, but GitHub, GitLab
not so sure. Maybe we could ask upstream to setup a webhook. Not sure.
cheers,
Gerd
_______________________________________________
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
