| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 16/06/16 09:34, Daniel Campbell wrote: |
| 5 |
> There is overhead in choosing which repositories you want to |
| 6 |
> include in your 'upstream'. Even with an automated tool like |
| 7 |
> layman, there's maintenance overhead. We'd need another tool to |
| 8 |
> assist in discoverability, too. Let's say this idea takes off and |
| 9 |
> we start with 100-200 user repos. It's meaningless to learn that |
| 10 |
> there are that many repositories and list them (that's what layman |
| 11 |
> currently does). What's important is getting a list of *which |
| 12 |
> packages* those repos have, even if it's one-by-one and cat'd to a |
| 13 |
> file. |
| 14 |
> |
| 15 |
> Even if that is written, it adds yet another facet to system |
| 16 |
> administration. |
| 17 |
I'm not convinced it will be a big amount of work, and I'm doubly not |
| 18 |
convinced most people will have *any* amount of work, as I expect most |
| 19 |
people do not care. (I would however be pleasantly surprised to be |
| 20 |
proven wrong.) They will start out with the Gentoo repositories, and |
| 21 |
only venture outside if they are aspiring devs, powerusers, or have |
| 22 |
some specific need that an overlay satisfies. If we have a useful |
| 23 |
website (and improved CLI layman-like tool for those who have |
| 24 |
webophobia), the complexity of assessing which overlay to use should |
| 25 |
be exclusively derived from actual assessment, not being bogged down |
| 26 |
in a hodgepodge of unreasonable tools. We should also have some way of |
| 27 |
measuring popularity, and let users show appreciation for |
| 28 |
repositories, so that there is a way to determine 'this is a top rated |
| 29 |
repository that many people use'. |
| 30 |
|
| 31 |
But, yes, unequivocally yes, there is an added level of system |
| 32 |
administration for those who choose it! I just happen to think it is a |
| 33 |
*desirable* addition for those who end up choosing it. |
| 34 |
|
| 35 |
> Okay, and who chooses which ones get curated? Developers? The |
| 36 |
> whole goal of this decentralization, from what I gather, is |
| 37 |
> community. If developers are overseeing it all, it adds overhead to |
| 38 |
> developers and doesn't really foster community control or support. |
| 39 |
I think it is a good idea to have our developers perform reviews and |
| 40 |
quality assurance. |
| 41 |
|
| 42 |
> If the goal is community then it should be *community curated*, |
| 43 |
> which means it can exist entirely outside of Gentoo's infra and we |
| 44 |
> shouldn't have to care about it. Why do Gentoo devs need to curate |
| 45 |
> it if the aim is community control? In fact, that's already |
| 46 |
> possible right here, right now. |
| 47 |
At first, I envision *community-assisted development* rather than our |
| 48 |
immediate retirement and holiday in the sun. It would however be good |
| 49 |
to aim *towards more community control*. Maybe in the future, instead |
| 50 |
of having a KDE team we have just one person or two (volunteers like |
| 51 |
now) who are performing a bit of review, QA, and coordination, of a |
| 52 |
small repository. Then perhaps in a more distant future it is entirely |
| 53 |
community driven. Stranger things have happened... But I would be |
| 54 |
happy to see the preceding success story, even if we don't get all the |
| 55 |
way. |
| 56 |
|
| 57 |
> I'm not against the idea per se, but at the same time I don't see |
| 58 |
> why it's the responsibility of developers to make this sort of |
| 59 |
> thing happen. It's not a trivial thing we can mark off in a |
| 60 |
> checklist. However, there are enough tools in the Gentoo toolbox to |
| 61 |
> make such a thing happen -- if the community wants it. And if they |
| 62 |
> want it, they can build it. We don't do anything, to my knowledge, |
| 63 |
> to stifle the growth of community repositories. |
| 64 |
I think we do a poor job of fostering the growth of community |
| 65 |
repositories, outside of making them possible in the first place. The |
| 66 |
latter is good, of course, and kudos to everyone who's worked on it. |
| 67 |
But it would be interesting to take it a step further and properly |
| 68 |
facilitate these repositories. |
| 69 |
|
| 70 |
And, again, modular repositories from our side, would make this that |
| 71 |
much more desirable. (And modularising the Gentoo tree is obviously |
| 72 |
our responsibility.) |
| 73 |
- -- |
| 74 |
Alexander |
| 75 |
bernalex@g.o |
| 76 |
https://secure.plaimi.net/~alexander |
| 77 |
-----BEGIN PGP SIGNATURE----- |
| 78 |
Version: GnuPG v2 |
| 79 |
|
| 80 |
iQIcBAEBCgAGBQJXYloNAAoJENQqWdRUGk8BMZQQAMt4qcmHlbSy7oOYVzjtP14C |
| 81 |
j3ROKwsWUS+n9Ejx9cbCShCxLNE7HfDK7SUxmf0LFvFKxOhrmjYmVZ2t8Iu07r6O |
| 82 |
8kK5pYlUenJtQKenMIsmMQclOFrRm/y0SX/PlDcmdwMgP+fqShy7zJ3u5JNKBwfr |
| 83 |
vitD0/c1rLS5C/p8p+o1w6g7RYUm6UtbPn8SjfkMorMpY1moU43BX4d/PFo4FT6B |
| 84 |
CtA5+df8Z5emUkKLDkiS/9xslVU53i1TZhycgOVbubMnyuvoJyHeB2ZWiSOtYqw7 |
| 85 |
GIUiYYmrQ6JJFf6ZNuIXV3V+zfv6nfNL5D9xvpBYg5RwMQEMUXWP8f0ca+2sE5Kx |
| 86 |
RojMEOKQx6Y1rYHOtq9gXpsAArT0TCWmglaxCqUwrf6SKL373TEkmr8RMvvRDGBV |
| 87 |
GFJcOsxv9OrkJTe0FYvmr8y8N93b+KTK7RhDekYuWm+rrbfebo+dcKPZmtPcYxoR |
| 88 |
NgmhLEdllUhdwti+e2Lo+qSXBScoRBeqYmWW+lN/k02YSV/gIiumbi7d4H/HRy6n |
| 89 |
kNbELzGpqLr/FIZRxD5Sx7ufSjEC+OlnP59OM6Uj1A6yUmuepyqlJJrmeaZ9LzGg |
| 90 |
6/vzgrX82jjrMAishtNleftquaxpzSNQsFGB1PgZ/h2XObacuBMnOgOMV8RvsfVG |
| 91 |
4VUp+ttdQi+DDxLQA4Bi |
| 92 |
=zHis |
| 93 |
-----END PGP SIGNATURE----- |
Archives