Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: james <garftd@×××××××.net>
Cc: gentoo-dev@l.g.o
Subject: Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
Date: Thu, 16 Jun 2016 15:53:22
Message-Id: 20160616175255.7d1d863e.mgorny@gentoo.org
In Reply to: Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project) by james
1 On Thu, 16 Jun 2016 09:40:53 -0500
2 james <garftd@×××××××.net> wrote:
3
4 > On 06/16/2016 10:04 AM, Michał Górny wrote:
5 > > On Thu, 16 Jun 2016 08:59:44 -0500
6 > > james <garftd@×××××××.net> wrote:
7 > >
8 > >> On 06/16/2016 02:51 AM, Alexander Berntsen wrote:
9 > >>> -----BEGIN PGP SIGNED MESSAGE-----
10 > >>> Hash: SHA512
11 > >>>
12 > >>> On 16/06/16 09:39, Daniel Campbell wrote:
13 > >>>> I guess what I mean is these outside developers could continue
14 > >>>> hacking and/or breaking things, or whatever else, without worrying
15 > >>>> about their "official" branch. We could have a standard that
16 > >>>> assumes Gentoo pulls their 'master' branch and they keep other
17 > >>>> stuff in 'dev', or some other model. We'll need to decide on *some*
18 > >>>> branch, but putting it in writing would make things clearer for
19 > >>>> prospective repo maintainers.
20 > >>
21 > >>> OK, then I think that it would be a good idea to have a gentoo-ci
22 > >>> branch, or similar, if the assumption is merely that this is where
23 > >>> Gentoo developers will look when evaluating your repository.
24 > >>>
25 > >> Ok, if we go this route, here is a basic simple question. Why can't the
26 > >> "gentoo-ci" be a package, or group of packages that runs in a private
27 > >> persons own resources, regardless it is a single gentoo server or a
28 > >> small cluster (openstack)? That way, those gentoo-ciruns can be
29 > >> performed by the proxy or the author thus reducing the workload for QA
30 > >> or other devs. I guess what I'm really asking is/will the gentoo-ci be
31 > >> packaged up for the gentoo community to use, on a small set of packages?
32 > >
33 > > dev-util/pkgcheck is the QA tool used (you want -9999).
34 > >
35 > > https://github.com/gentoo/travis-repo-checks is the wrapper that is
36 > > used to run it in parallel. A lot of hackery, and master is outdated
37 > > for -9999. No time to fix it. The repo-mirror-ci branch is better but
38 > > then, I updated it recently for some local hacks.
39 > >
40 > > https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
41 > > to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
42 > > especially with the error & warning lists hardcoded.
43 > >
44 > > https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
45 > > used to run it all. No time to clean it up more than I already did.
46 > >
47 >
48 > EXCELLENT ! I seem to be mostly interested in orphaned, broken and
49 > controversial packages these days....not sure if that is a good thing or
50 > not.
51 >
52 > Do these ci tools work on gentoo snaps? [1]
53
54 I have no clue. And I doubt I'll be interested in testing that thing.
55
56 > [1]
57 > http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/
58
59 --
60 Best regards,
61 Michał Górny
62 <http://dev.gentoo.org/~mgorny/>