Re: Dist-git for Copr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 6 Sep 2014 17:22:32 +0200
drago01 <drago01@xxxxxxxxx> wrote:

> On Sat, Sep 6, 2014 at 5:07 PM, Dennis Gilmore <dennis@xxxxxxxx>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thu, 04 Sep 2014 17:34:57 +0200
> > Miroslav Suchý <msuchy@xxxxxxxxxx> wrote:
> >
> >> Hi,
> >> we (the Copr team) would like to allow uploading of source RPM to
> >> Copr. It seems that best way is to utilize dist-git [1]. Then Copr
> >> will fetch sources and spec file from dist-git and build SRC.RPM
> >> the same as Koji does now. And hopefuly you will be able to use
> >> fedpkg to interact with Copr.
> >>
> >> I see two options available: Copr will have its own dist-git
> >> instance or we will share dist-git together with Fedora. There are
> >> pros and cons for both and I would like to summarize it.
> >>
> >> 1) Copr will have its own dist-git instance
> >> Pros:
> >>   * no possible conflicts with Fedora
> >>   * installation of dist-git is tracken in ansible playbook in
> >> infra.git, so it should be straightforward (although Pavol
> >> Babincak - current maintainer of dist-git - claimed he had hard
> >> times to reproduce the installation) Cons:
> >>   * require additional machine (Fedora currently use 8GB RAM + 2 GB
> >> swap and 1 TB of disk)
> >>   * and additional maintance (although Pavol Babincak claims that
> >> there are no problems with running instance, he barely need to
> >> touch it)
> > Pavol is one of the maintainers he is not the only one.
> >
> >
> >> 2) Copr will share dist-git with Fedora
> >> Pros:
> >>   * no maintenance of new machine
> >>   * a lot of source are same and shared in look-aside cache (less
> >> data stored)
> >>   * technically easily possible. E.g. for package 'rpm' in Copr
> >> project msuchy/foo we can create branch 'msuchy/foo' of dist-git
> >> 'rpm'. There are separate ACLs for each branch, so owner of
> >> 'msuchy/foo' branch could not affect branch 'f20' and vice versa.
> >> Cons:
> >>   * dist-git use MD5 for checksum [2] therefore it can be
> >> practicaly possible to find collision with existing tar.gz and
> >> upload new version and Koji will use that file instead.
> > I do not see this as a huge issue
> >
> >>   * Koji currently build from given SHA of commit of dist git and
> >> does not check if it is in correct branch. Therefore it can be
> >> theoreticaly possible to submit to Koji build from Copr branch.
> >> Afaik you still have to have ACL for that given branch in Fedora,
> >> so only Fedora package maintainer can do that and he obviously
> >> have no reason for that, but still... technicaly possible.
> > as long as the commit is in git anyone with a koji cert (i.e.
> > potentially anyone who has signed the fpca) can submit a build.
> > until we have ways to make sure builds are from an appropriate
> > branch in koji I will strongly oppose sharing of dist-git
> >
> >
> >> * Legal differences - users of Copr does not have to belong to
> >> CLA_DONE group. Can it make some problems? I do not know.
> > yes it can, I do not think we should accept contributions from
> > people who have not agreed to the fpca. I do not want to get into a
> > situation where a fedora maintainer pulled commits from a copr repo
> > into Fedora and we are being asked to remove them because they
> > legally could not contribute.
> 
> Huh? What makes one legally not eligible to contribute? Just not
> signing the fpca? How is that different from someone that submits a
> patch via bugzilla / mail / whatever?
> I don't think people check whether those patch submitters have signed
> the fpca and neither do I think they should.

The difference as I understand it is not the contents of the patches
etc, but to do with the work of contributing directly to fedora. If you
applied the patches while at work for an employer, and your employer
turns around and asks us to remove the works since you did not have
their permission to make the contribution[1]. where a patch either has
a copyright attached or we assume its under the same terms as the
upstream project. It is less to do with the content and more to do with
the specific actions of the person. Maybe it is less relevant in the
FPCA world but I am not a lawyer and err on the side of caution.

Dennis

[1]
https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUDckoAAoJEH7ltONmPFDRTlwP/3FPNp4mQtD9X4pvnAY6/bDx
eNgG9K66BSV70TWhO5qUaVgL3AnYiY5SArI97srCDy+GJQzZZ3M1kuVjc6FcpWAa
9NC42WDvv7w+rbVRq68gfLQds9JHA/HaKaQlFYdIHPgOcPvrmk5eXyUnIr18joAj
2A0eWcSDl5b9LI4gxQMv5oIhCFhbcM+g1zn58QeqWYCVrkaZPaFxQFDWYLP8NGaH
U0T1eG99V4kpY1U7z6ZkJptnEOYD8kunF2RcYwCZL8hvwM3YZZ1XW3q6yt4KRWHf
0xOel5UZ4A95Uhf8qlF/lDEkw7/PeCVMM8eeXyvrDegVI4JAsPUGJitR8aT1ZFyA
3roBhLmqa+URBGjC1+zs2dBj5oB+ZW75KNRyaBRD1R7We3oygm6kNWMujqsBPOjZ
46OyYTOccWbzrLw8ad41m+WCTw62wZi/DaLi4oLaECK5acz5kAuPM/QX84wgGKIL
e4DTMjyNXHk7fgLbSdXZCNmoaTYTRdjHsdCq3Ayy4Da6itdtNAyjmD5UGKLtASPf
xyCfmSras/ivSGTvz32l/w+vM8TBip/e7m/2FEPHb8sDjk6gW85KYjxqEon/tGNM
90MpCrvgZ6mfAtg4v7iTkCbm4BtRzOSrd0rBSmRF8zV5WvEWFcQYjZoqwlWJlolQ
lSlBHB3NyBem8zmZjO4v
=rnOn
-----END PGP SIGNATURE-----
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux