----- 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/in...
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks(a)lists.fedoraproject.org
>
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
>
--
Regards,
Bohuslav "Slavek" Kabrda.