| 1 |
On Sat, 9 Dec 2017 23:21:57 +0000 |
| 2 |
"Robin H. Johnson" <robbat2@g.o> wrote: |
| 3 |
|
| 4 |
> I did wish to participate re two items here, but regretfully I will be |
| 5 |
> travelling at the time, and it's unlikely that I will have |
| 6 |
> connectivity. |
| 7 |
> |
| 8 |
> On Sat, Dec 09, 2017 at 08:39:54PM +0100, Andreas K. Huettel wrote: |
| 9 |
> > 3. Final review of GLEP 74 [4,5] |
| 10 |
> > -------------------------------- |
| 11 |
> > Full-tree verification using Manifest files |
| 12 |
> The implementation is done, some tweaks were made since the previous |
| 13 |
> month's version. |
| 14 |
> |
| 15 |
> > 4. Restricting gentoo-dev/-project posting [6] |
| 16 |
> > ---------------------------------------------- |
| 17 |
> > * Restricting posting to both gentoo-dev and gentoo-project, while |
| 18 |
> > creating a gentoo-experts list? |
| 19 |
> > * Restricting posting to gentoo-dev and moving all official |
| 20 |
> > business there? |
| 21 |
> > * Restricting posting to gentoo-dev and moving all official |
| 22 |
> > business to a revived restricted gentoo-council list? |
| 23 |
> > * Moderating lists instead? |
| 24 |
> I had not weighed in publicly on this before, but wish to make a |
| 25 |
> statement. |
| 26 |
> The original split of gentoo-dev to gentoo-project included |
| 27 |
> moderation of gentoo-dev, however that was never really implemented, |
| 28 |
> mostly for technical reasons, and a decreased need after the split. |
| 29 |
> |
| 30 |
> I oppose a further split of -dev/-project/-experts, and instead |
| 31 |
> propose better list policies of -dev. If it's technical, even coming |
| 32 |
> from an expert user, it probably belongs on -dev. If it's about the |
| 33 |
> organizational structures of Gentoo, it belongs on -project. |
| 34 |
> How do we keep the threads more on-topic? Moderation maybe, but I'm |
| 35 |
> not convinced that is best. |
| 36 |
> |
| 37 |
> |
| 38 |
|
| 39 |
|
| 40 |
I second this. I too do not want to see the lists split even further. |
| 41 |
There are far too many interested and competent users in it that can |
| 42 |
and do contribute in some ways. There has to be a better solution. |
| 43 |
|
| 44 |
|
| 45 |
Also: |
| 46 |
|
| 47 |
1. Lack of enough package maintainers [1] |
| 48 |
----------------------------------------- |
| 49 |
Anything that can be done? |
| 50 |
|
| 51 |
|
| 52 |
I am intending to set up a buildbot instance and develop some builder |
| 53 |
scripts for it to aid in regular package maintenance. It should be |
| 54 |
able to do basic version bumps and run the test suite, present it to the |
| 55 |
pkg maintainers for final Q/A and pushes to the tree. It should also be |
| 56 |
able to check/test on whatever arches that have a worker connected to |
| 57 |
it. So this should help take some of the pressure off the various arch |
| 58 |
teams. My first goal is for it to do many of the python pkgs I |
| 59 |
maintain to get the basic system up and running. Plus I should be able |
| 60 |
to leverage some of the g-sorcery/gs-pypi code. Once operational, it |
| 61 |
should be possible to add additional parsers to check for and update |
| 62 |
dependencies to add additional types of pkgs to its capabilities. |
| 63 |
|
| 64 |
I will be able to have it run on amd64, x86 and arm64 arches with the |
| 65 |
equipment I have. Plus I have had others say they could help with |
| 66 |
additional arches such as an armv7 cluster. So, this should also help |
| 67 |
with keywording demand. |
| 68 |
|
| 69 |
|
| 70 |
|
| 71 |
|
| 72 |
|
| 73 |
-- |
| 74 |
Brian Dolbec <dolsen> |
Archives