From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0E12D15808B for ; Thu, 31 Mar 2022 02:00:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BBFBBE0794; Thu, 31 Mar 2022 02:00:55 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 03802E076B for ; Thu, 31 Mar 2022 02:00:54 +0000 (UTC) Received: by smtp.gentoo.org (Postfix, from userid 559) id BFBAF3412F7; Thu, 31 Mar 2022 02:00:52 +0000 (UTC) Date: Wed, 30 Mar 2022 22:01:07 -0400 From: Mike Frysinger To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] utilizing GH functionality that Gentoo infra does not provide Message-ID: Mail-Followup-To: gentoo-project@lists.gentoo.org References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wh9CceCZ7oQf0Ew2" Content-Disposition: inline In-Reply-To: X-Archives-Salt: 20c07c68-1a01-4b49-8227-8018690f996f X-Archives-Hash: f560cfb0eb99d9e13d8b69f817917e32 --Wh9CceCZ7oQf0Ew2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 29 Mar 2022 12:29, Alec Warner wrote: > On Tue, Mar 29, 2022 at 10:56 AM Mike Frysinger wrote: > > starting a dedicated thread for > > https://archives.gentoo.org/gentoo-project/message/ec2b560480627371a7bd= a5c85924eddd > > > > GH provides a lot of functionality for free that Gentoo infra does not = cover. > > these are particularly useful for projects that are used beyond Gentoo. >=20 > GH is non-free, and so in the spirit of the social contract, I do not > believe it should be used. Arguably it shouldn't be used now, but we > have not stood up an alternative. The alternative is currently in > alpha (see notes below.) this argument doesn't really hold water. we already have core packages (e.= g. portage & catalyst) that hard depend on 3rd party packages that only exist = on GH. we also have many 1st party packages (i.e. ones authored by Gentoo dev= s) that only exist on GH. this includes core python packages as well as both = of the init systems that Gentoo uses (OpenRC & systemd). the proposal isn't talking about using GH for code hosting. that remains on Gentoo infra. it also isn't about issue tracking which we have bugs.g.o fo= r. this is about features that cost nothing and aren't problematic if they're lost (i.e. GH shuts down). further, let's see what the social contract actually says: > We will release our contributions to Gentoo as free software, metadata or > documentation, under the GNU General Public License version 2 (or later, = at > our discretion) or the Creative Commons - Attribution / Share Alike versi= on > 2 (or later, at our discretion). Any external contributions to Gentoo (in > the form of freely-distributable sources, binaries, metadata or documenta= tion) > may be incorporated into Gentoo provided that we are legally entitled to = do > so. However, Gentoo will never depend upon a piece of software or metadata > unless it conforms to the GNU General Public License, the GNU Lesser Gene= ral > Public License, the Creative Commons - Attribution/Share Alike or some ot= her > license approved by the Open Source Initiative (OSI). all the code is still GPL-2, and we're hosting it. if you're going to try and argue that the hosting services of software we depend on all have to be FOSS, then that ship sailed long ago (if it even ever made it to port). it's logically reductive to the point of irrelevanc= e. do we require our mirrors to only run FOSS when they host our distfiles or rsync trees or git repos ? if we're running in a VM, do we require the VM host to only run FOSS ? if it's running in a container, do we require the container software & host to only run FOSS ? do we require the hardware vendors themselves to be FOSS (i.e. Intel's ME & firmware) ? where exactly does it end ? > > * CI runs (e.g. GH actions) >=20 > We have CI but it's mostly not self-service and the primary issue on > the infra-side is always resources / people. I agree we should aim for > something more accessible. i don't see why we would waste our money & resources when there places like GH are throwing tons of free resources. is our CI going to support multiple OS's ? are we going to pay the licensing fees for running on proprietary OS's (e.g. Windows) ? what about multiple Linux distros ? multiple arches= ? can it actually scale to all our needs ? who gets to maintain all that and actually keep it working ? this is more than a full time job, and asking every dev to chip in only leads to infra that risks falling apart every other week. does it really make sense to spend limited engineering time requiring everyone to use these subpar systems ? if people want to volunteer to work on it for Gentoo, that's fine of course, but that doesn't mean we should require every Gentoo project to only use these. > > * Projects for task management >=20 > I'm not sure what this is (I haven't used it.) We use bugzilla for > task management (issues) and mailing lists (for discussion.) I'm not > sure github issues are "better" but they do have some advantages; I've > gotten complaints about bugzilla, particularly on mobile. Plus you > cannot reply to bugs easily via email. >=20 > For the time being the gitlab alpha does not intend to move issues out > of bugzilla; nor use gitlab for discussions; aside from discussions on > PRs (which will be on gitlab.) the lack of e-mail gateway is kind of annoying. i'm not super tied to this particular feature, just another one that i noticed could be of value, and where bugzilla is a poor substitute. not sure how many projects would use it in practice. gitlab seems to support these though, so it's less of an issue. > > * possibly even Discussions since it'll provide a clear/scoped space for > > non-Gentoo users & devs. Gentoo forums are huge and require custom acct= s, > > and mailing lists are huge and a bit restrictive old timey. >=20 > We have an SSO solution (sso.gentoo.org) that we are rolling out for > developers, and our gitlab (in alpha testing) will support external > account providers (probably google, gitlab, github accounts.) >=20 > I'm honestly unsure how to receive feedback like "mailing lists are a > bit restrictive old timey". What does that mean? >=20 > - It's hard to know which list to email. > - I often have to subscribe to the list to post. > - Hard to have pretty content in an email. managing subscriptions is archaic. it's been archaic for years. you have to manually construct the e-mail address to send messages to. https://www.gentoo.org/get-involved/mailing-lists/instructions.html jumping through these hoops just to start a conversation means people don't. mailing lists have fallen out of favor as modern communication methods -- s= ee the rise of web-based services. i'm not suggesting we migrate to e.g. slac= k. more to the point, we don't have localized low-friction spaces. we don't have that many mailing lists. they lock out people (e.g. gentoo-dev) or they're large & noisy (gentoo-users) or they're still larger in scope (e.g. the arch lists). creating mailing lists is painful, and doesn't help that much with the other points. > > this is all orthogonal to the git content itself (objects, branches, ta= gs, > > etc...). those should remain in the read-only clobber mode that exists = now. > > > > there is no downside for Gentoo here. it's all functionality that can = be > > had for free, does not introduce any risks, and many devs are already u= sing > > GH heavily for Gentoo projects -- albeit, they don't do it under the Ge= ntoo > > umbrella, they fork it into their own personal space and maintain it th= ere. > > we shouldn't be forcing devs & projects away from Gentoo for such basic > > functionality. >=20 > I think you present a 'free lunch' here and I'll just say "there is no > such thing as a free lunch." The downside is that we present Gentoo as > an open distro that doesn't depend on proprietary software, but is > developed using Github, a proprietary solution that provides all this > cool functionality that we don't have implemented in house. In general > that's not a sustainable approach. I get that we make tradeoffs > (firmware, drivers, being an obvious place where compromises are > made.) I'm not sure I'm willing to support this one. are you planning on mandating @system packages and all their deps to not use GH ? or packages that Gentoo devs are maintaining that are only used by Gentoo to not use GH ? or that those packages have to use GPL-2(+) ? there's a number of core Gentoo projects right now that are absolutely violating the social contract by using BSD licenses instead of GPL, but no one is saying anything about it. are you saying that things like Gentoo/Prefix are not welcome here just because they run on Windows or macOS or other proprietary OS's ? there's a lot of code that isn't useful at all when you take away these things. i think you're extrapolating the social contract beyond what it actually is. Gentoo isn't GNU. everything we produce is FOSS which is what the social contract dictates. it isn't that everything has to be GPL down to the CPU. not all Gentoo projects are purely about Gentoo. they might have started here, and focus on here, but are usable beyond. how does kicking them out of the Gentoo umbrella help anyone ? -mike --Wh9CceCZ7oQf0Ew2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmJFC2IACgkQQWM7n+g3 9YGJ/Q//TmGeD5xwbfDcwoaM8sSvmUW2N7qCTFvDv5RwEW/KQ2th0cBw+k10T8I4 5640a9nirpjJgWGvBfyYedNph1psJUgM3UGYZ2WzXgrcZTpSmgHTXe7OjULfoeIA aunx8Ca+SboeJBIPK9rnNPb6JVlYaBAMUuAU8mc9wuivSQ+Fx/lG2IxBZzCuf6AR 9XfIi+xq3lAVnmMzoLohfGBOy2ybZnWyDqm05KpLCbKinCBvk/fyYec2xGb9NL0e Mv8KhyOc/doQqkpk1TMARE0pVi3E8sBVwLAouGvD/0A37+oMyR3wzIhJcXY4omOi w4Nx1ONjERQ6zI3c12H5nxFFY3++bsjZzP7Lu5mgJOC6ec9tn1zMXCSfJVX7dRw6 Yls84hyen6NG8Z8crmx4OBBGUqlolj1kWfEdRtXTTVsGbAbQkrij9QYITjWDxYdz +8tsJorq1aUqPo0qHw6+cjArefqu5p1AU3KhSrpkpnLpjlS+SSXwoAM3hX90MXCz lg1tLki0Pw1TNjYYap+2LAqcQC+K7sdIguG4oID7xeDuw2E6eAd9wdEb8zaK7Zue 52I5sO7oj/jk9kOStcrdizhzJlzDYBgPZORLK0sUtYkwYut96UjUtaNK9mZW0pik PwNPViWMAn/hgtTWjACqdifBNzouG3KmF8OgT71jEX9BbCY8tQk= =BjSp -----END PGP SIGNATURE----- --Wh9CceCZ7oQf0Ew2--