Git for Copr

Tadej Janež tadej.janez at
Mon Mar 3 00:01:31 UTC 2014

On Wed, 2014-02-26 at 08:32 +0100, Radek Vokál wrote: 
> So would something like make more sense - eg. package 
> hosting service layer between github and copr.

I had a quick look at and to my understanding it only
provides (free for open-source software) package repository hosting (and
some Jenkins integration).
Based on that I would say that this is not what I had in mind with
GitHub-like layer on top of COPR.

As I see it, the main benefit of using GitHub (or something alike) is to
extend *basic* COPR repositories with SCM, lightweight issue reporting
and improved collaboration options.

> Anyway, I think it's important to list the desired usecases.


> For example 
> I don't see an easy way how to fork certain package and start 
> development and testing some experimental feature that might not get 
> into head in a couple more releases.


I came up with 3 additional use cases:

1) Complex upstream project with many dependencies and needing a lot of
patches that is not interested in making a Fedora package (or making
such package is not of high priority).
- It could clearly use its own downstream issue tracking.
- It will need collaboration options since it will likely be
co-maintained by more than one packager.

2) A packager testing new (improved) ways of packaging some application.
- The packager could fork the package's repo, start making changes to
the SPEC file and/or patches, request COPR to rebuild the modified
package and finally test and share the built package(s).
- In cases where this effort would require collaboration, it will be
useful to have the ability to give in-line comments to SPEC files and
patches, send pull requests, ...

3) A new Fedora contributor requesting a review of his package so it
could be included in Fedora's main repository.
- The reviewer could provide in-line SPEC comments
- The reviewer could fork the package's repo, make the desired changes,
request COPR to rebuild the modified package and test it (it would be
simpler and faster than doing it manually, as is the case nowadays).


More information about the env-and-stacks mailing list