Git for Copr

[Tadej Janež]

Hi!

Slavek, thanks for a thorough email.

On Mon, 2014-02-24 at 06:43 -0500, Bohuslav Kabrda wrote: 
> However, few other people also joined the discussion and the responses to this idea were more like:
> - Why do we want to do this? This seems to be like creating Koji from Copr. Copr should remain lightweight.

Hmm, I don't follow how this would mean creating Koji from Copr. For
example, Koji doesn't handle things like SCM, pull requests, inline code
comments, lightweight issue tracking?

> - Why would we need web interface? People don't need/want it.

Hmm, who is people? Where do you get this impression from?
In my opinion, GitHub's popularity speaks against that.

> - If we really need web interface, why don't we utilize fedorahosted.org?

I think fedorahosted.org has many drawbacks, which is demonstrated by
its unpopularity. Of course, it would be great to work on improving
fedorahosted.org and bring it back to being state-of-the-art for project
hosting, but this will likely take a lot of time.
Hence, I think it would be easier and faster to create a "thin
GitHub-like" layer on top of COPR.

> - Why don't we just allow people to utilize any git (private git repo, git hosting like Github)

This would be another possible alternative to building a "thin
GitHub-like" layer on top of COPR.

> and provide just tool that would allow users to do "copr build" and it would work automatically

Yes, that could also work.

In relation to the "Fedora ugly" repo, we have to think about where to
put the functionality that would enable a packager's workflow to include
his package/repo in the "Fedora ugly" repo.
I'm thinking of things like:
1) propose a package/repo for inclusion
2) get the results of the automatic review
2a) get help with the items that didn't pass review
2b) report a problem in the automatic package review
3) update the approved package in the "Fedora ugly" repo
4) add a co-maintainer of the package in the "Fedora ugly" repo
5) pull a package/repo from the "Fedora ugly" repo

Would we put this into COPR, tool like Tito or this "thin GitHub-like"
layer on top of COPR?

> (actually it seems that Tito already knows how to do this [1]).

(I haven't heard of Tito before, so thanks for the pointer!)

> My opinion on this is:
> - Utilizing git for tracking changes is important for example for the "fedora-ugly" idea, where we would like to easily track/view specfile history.

+1

> - Having a single central place for git repos and offering it to Fedora contributors to use would be a nice addition.

+1

> Utilizing fedorahosted.org for this usecase might be nice and we could reuse what we already have (although personally I find fedorahosted user experience pretty clumsy).

Like you said, fedorahosted.org feels clumsy and out-dated. See also my
point above.

> - At the very least, we could extend the Tito Copr releaser to add some sort of meta-tag to specfile (someone mentioned that this should be possible) containing git url and hash. This way, we would be able to track the repo that srpm came from and the commit hash - again, this would improve the experience for potential contributors, who would be able to easily find where to send pull requests/patches.

+1

> Overall, I think this would improve Copr user experience and soften the sharp edges that might otherwise scare potential Fedora contributors.

+1. And it's not just about scaring potential Fedora contributors. We
want to make package maintenance as easy and automated as we can to
lessen the burden of existing packagers.

> Also, having git repos would IMO significantly improve the possibilities of collaboration and tracking - compared to throwing bunch of srpms into Copr by hand.

+1.

> I don't think that we necessarily need to provide the hosting for this, but we should definitely provide a howto guide that would describe how to _easily_ achieve this with e.g. Github/Bitbucket repos and so on.

This is an important point. If we decide that it is ok to rely on
external project hosting services like GitHub/Bitbucket, we get all of
the benefits of their work-flow for free, minus the drawbacks of using
such heterogeneous services (e.g. distinct user interfaces).

I put "if we decide it is ok" since relying on external hosting bring
some questions (I'll use GitHub in the questions, but any GitHub-like
external service has the same issues):
- How do we deal with cases when a user, who is no longer interested in
his package/repo, deletes it from GitHub? Will we host private git
mirrors of external git repos for such cases?
- The transition to the Fedora "Collection" (i.e. main repo) will be
seen as a step back-wards with respect to the work-flow that GitHub
enables. Will we allow packages that went under proper (old style)
review to use GitHub for SCM?
- How do handle the downtime of GitHub? Or what to do if they, for some
unknown reason, change their policy to start charging for using/viewing
it? ...


> Again, we should show an easy way for potential contributors, who may enter Fedora by building in Copr.

+1.

Regards,
Tadej