Gentoo Archives: gentoo-project

From: Brian Dolbec <dolsen@g.o>
To: gentoo-project@l.g.o
Cc: gentoo-dev@l.g.o
Subject: [gentoo-project] New gen-b0rk repository specifically for Q/A tools testing
Date: Sun, 01 May 2016 23:54:17
1 In order to further improve the chances of Q/A tools catching
2 errors. I have created a new repo (overlay) which will contain minimal
3 test case ebuilds. The idea is to have test case ebuilds to run
4 repoman code against. The outcome of these runs should be comparable
5 to pre-recorded output. In that way as more code changes are applied
6 as part of the stage3 re-write as well as new test cases and checks to
7 be added to it's capabilities. It should minimize the bugs introduced
8 in releases.
10 Repoman does have some unit tests, but it is far from 100% coverage.
11 Also with the major structural changes that the code has been
12 undergoing, it is not always possible for the unit tests to be
13 compatible with the new code.
15 This new repository is open to all Gentoo developers to contribute to.
16 All we ask is that you follow some simple common sense rules for adding
17 additional test ebuilds.
19 The repo is located at:
23 Here is the README included in the base directory.
25 This repository is for the primary purpose of testing Q/A tools like repoman.
27 The ebuilds it contains are for testing specific areas of tests that are
28 performed as part of the normal operation of that Q/A tool.
30 This repository is open to all Gentoo developers under the following rules:
32 1) The master branch is to remain the stable Q/A testing branch.
34 2) All ebuilds are to be minimal test cases.
36 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect.
37 This makes it easier to spot errors during code development. Simply running
38 repoman in a category should be enough to test everything the module tests.
39 This excludes some commit only checks which can be run in a local only branch.
41 4) All category names are to represent the Q/A category being tested.
42 ie:
43 ebuild-test - tests various aspects of the ebuild repoman module
44 eclass-test - various eclass module tests
45 ...
47 5) like the category naming, the package naming will follow the test
48 being performed.
49 ie:
50 eclass-test/live-keywords - test the eclass module LiveEclassChecks
51 keywords check
52 ebuild-test/invalid - test for invalid package name detection
54 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo
55 That should ensure it maintains co-ordination with the main gentoo repo.
56 All new or modified eclasses that affect pkg metadata should be validated in
57 a branch.
59 7) New module development and test ebuilds will be done in a branch or personal
60 repo and submitted to the gentoo-portage-dev email list for review and
61 approval to merge into master.
62 NOTE: This rule is lifted for the initial creation and population of
63 test ebuilds to use to test out the repoman code. An anouncemnt to
64 the gentoo-project email list will be made when this initial population
65 period is being ended.
67 8) Signed commits only, also signed-pushes are mandatory
69 9) The metadata category will get files of validated output that can be used
70 to verify code changes in the various categories and repo wide runs.
71 Diffing the output, should help to verify code changes did not break anything.
73 10) See rules 1-9 :-)
75 --
76 Brian Dolbec <dolsen>