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/> |