| 1 |
On Sun, 9 Apr 2017 15:20:02 -0700 |
| 2 |
Brian Dolbec <dolsen@g.o> wrote: |
| 3 |
> |
| 4 |
> This could be partially automated using buildbot. The easiest would |
| 5 |
> be for pkgs containing working test suites. Those that pass could be |
| 6 |
> auto-enabled with that python with ~arch keywords. I think if a |
| 7 |
> stable pkg is to be added the new python, it should be via a revision |
| 8 |
> bump and ~arch'ing the keywords. But we could enforce the bot to |
| 9 |
> rev-bump all ebuilds just as easily. |
| 10 |
|
| 11 |
If the package failed, all that would need to be done kinda like now is |
| 12 |
a given variable modified in the ebuild. Just marking what ever it did |
| 13 |
not work with. As mentioned that could be done via my |
| 14 |
ebuild-batcher[1], though same functionality is easily replicated. |
| 15 |
|
| 16 |
I also have an ebuild-bumper[2], that could be made more advanced. I am |
| 17 |
aware of ebump, but ebuild-bumper is a bit different. It works with |
| 18 |
sets of ebuilds for bumps and cleaning. It can do individual as well |
| 19 |
but so can ebump. |
| 20 |
|
| 21 |
I plan to further automate ebuild-bumper with something that tracks |
| 22 |
upstream releases and attempts to automate bumps. Though even running |
| 23 |
it manually is not cumbersome. Just prefer zero day as much as possible. |
| 24 |
|
| 25 |
1. https://github.com/Obsidian-StudiosInc/ebuild-batcher |
| 26 |
2. https://github.com/Obsidian-StudiosInc/ebuild-bumper |
| 27 |
|
| 28 |
-- |
| 29 |
William L. Thomson Jr. |
Archives