| 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. |
| 9 |
|
| 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. |
| 14 |
|
| 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. |
| 18 |
|
| 19 |
The repo is located at: |
| 20 |
|
| 21 |
https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ |
| 22 |
|
| 23 |
Here is the README included in the base directory. |
| 24 |
|
| 25 |
This repository is for the primary purpose of testing Q/A tools like repoman. |
| 26 |
|
| 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. |
| 29 |
|
| 30 |
This repository is open to all Gentoo developers under the following rules: |
| 31 |
|
| 32 |
1) The master branch is to remain the stable Q/A testing branch. |
| 33 |
|
| 34 |
2) All ebuilds are to be minimal test cases. |
| 35 |
|
| 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. |
| 40 |
|
| 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 |
... |
| 46 |
|
| 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 |
| 53 |
|
| 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. |
| 58 |
|
| 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. |
| 66 |
|
| 67 |
8) Signed commits only, also signed-pushes are mandatory |
| 68 |
|
| 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. |
| 72 |
|
| 73 |
10) See rules 1-9 :-) |
| 74 |
|
| 75 |
-- |
| 76 |
Brian Dolbec <dolsen> |
Archives