Git for Copr

[Bohuslav Kabrda]

----- Original Message -----
> Thanks, Slavek! I'm very positive about the general way of the
> discussion's results -- just making things easy and working with any
> public git repo -- this is really what I like.
> 
> However, I'm not following exactly what would the proposed opinion mean
> for users (a user here may be a Fedora new-comer or beginning packager)
> in practice. What I'd like to see is:
> 
> Scenario 1) A user already has a repo (say on github), while there
> already is a spec file and tar ball generated. Then he doesn't need any
> other layer and should be able to approach Copr directly, specify an
> urls to:
> * the git repo + spec file path (+ a branch/hash?)
> * the already generated tar ball
> and he should be done.
> 
> Scenario 2) A user has only a git repo with source files, but there is
> no tar ball released, no spec file. Then he would approach "the
> git-based layer" between Copr and his remote git repo, created a spec
> file and patches, he would specify how to generate a tar ball and then
> he would continue like a user in scenario 1).

Hi Honza,
yeah, these are valid use-cases. What I had on my mind was (dumping some ideas here):
Scenario 3) There is a central git repository that follows these rules:
- each repo is identified by user and package name (bkabrda/python)
- each repo has 1 to "n" branches, each branch corresponds to one copr repo (e.g. python3.4)
- other users can clone a repo and send pull request/patch to the owner
- invoking "somecoprtool build" automatically knows that it should build the srpm in copr repo bkabrda/python3.4

Hope this makes sense,
Slavek.

> I'm not sure how far away this approach is from your approach. I just
> wanted to create a real use case example here. If there are some
> significant differences, please, help me understand them.
> 
> Cheers,
> Honza
> 
> On 02/24/2014 12:43 PM, Bohuslav Kabrda wrote:
> > Hi all,
> > at last Env and Stacks WG meeting I've promised to talk to Mirek Suchy,
> > Copr maintainer, about providing sort-of-dist-git (*), perhaps with a web
> > interface, for Copr.
> > The result of the discussion from Mirek's side is, that he's ok with it as
> > long as he doesn't have to do it, since he's fully occupied with Copr.
> > Also, Copr should still provide the option to build packages as it does
> > now, e.g. sort-of-dist-git should be just a frontend application (not part
> > of Copr), not really something that would be tied directly into Copr.
> >
> > 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.
> > - Why would we need web interface? People don't need/want it.
> > - If we really need web interface, why don't we utilize fedorahosted.org?
> > - Why don't we just allow people to utilize any git (private git repo, git
> > hosting like Github) and provide just tool that would allow users to do
> > "copr build" and it would work automatically (actually it seems that Tito
> > already knows how to do this [1]).
> >
> > 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.
> > - Having a single central place for git repos and offering it to Fedora
> > contributors to use would be a nice addition. 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).
> > - 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.
> >
> > Overall, I think this would improve Copr user experience and soften the
> > sharp edges that might otherwise scare potential Fedora contributors.
> > Also, having git repos would IMO significantly improve the possibilities
> > of collaboration and tracking - compared to throwing bunch of srpms into
> > Copr by hand.
> > 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. Again,
> > we should show an easy way for potential contributors, who may enter
> > Fedora by building in Copr.
> >
> > Regards,
> > Slavek.
> >
> >
> > (*) By sort-of-dist-git, I mean a place for git repos that would hold
> > specfiles/patches, etc., e.g. what Fedora's dist-git holds, but possibly
> > without the lookaside cache... Details to be discussed.
> >
> > [1]
> > http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/index.html
> > _______________________________________________
> > env-and-stacks mailing list
> > env-and-stacks at lists.fedoraproject.org
> > https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
> >
> 
> 

-- 
Regards,
Bohuslav "Slavek" Kabrda.