| 1 |
On Mon, 10 Jul 2017 15:41:04 +0200 |
| 2 |
Kristian Fiskerstrand <k_f@g.o> wrote: |
| 3 |
|
| 4 |
> On 07/10/2017 03:35 PM, Kent Fredric wrote: |
| 5 |
> > On Mon, 10 Jul 2017 13:43:43 +0200 |
| 6 |
> > Pacho Ramos <pacho@g.o> wrote: |
| 7 |
> > |
| 8 |
> >> Yes, but it's similar as the cases when we need to fix our packages |
| 9 |
> >> to work with a newer library they depend on. In this case it would |
| 10 |
> >> be even easier as we can have multiple python versions and switch |
| 11 |
> >> to the newer one for testing while going back to the stable one (if |
| 12 |
> >> preferred) later. |
| 13 |
> >> |
| 14 |
> > |
| 15 |
> > I'm starting to think we need a collection of QA scripts in a repo |
| 16 |
> > somewhere, optimized for symlinking into /etc/portage/hooks/install/ |
| 17 |
> > |
| 18 |
> |
| 19 |
> I might've read things too quickly, we're not talking a repoman check |
| 20 |
> here? |
| 21 |
> |
| 22 |
|
| 23 |
Yes, the warning would be a repoman check for version bumps, etc... |
| 24 |
|
| 25 |
What he is talking about, is OT, and I want to automate with a buildbot |
| 26 |
instance that can do automated testing for all python pkgs (to start |
| 27 |
with) that have tests enabled in the ebuild. I am also planning to |
| 28 |
help with automatic version bumps for those pkgs as well. If not |
| 29 |
committed straight to the tree, then emailed as a patch to the |
| 30 |
maintainers, perhaps in a pending repo/branch, bugzilla... TBD. |
| 31 |
|
| 32 |
|
| 33 |
Oh, and I want to connect as many arch specific workers to it as well. |
| 34 |
|
| 35 |
That should ease ebuild bumps, PYTHON_COMPAT and keywording |
| 36 |
maintainence. |
| 37 |
|
| 38 |
Once in place and operational, it should give the groundwork to add |
| 39 |
other pkg types, not just python based pkgs. |
| 40 |
-- |
| 41 |
Brian Dolbec <dolsen> |
Archives