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