From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Call for project proposals: Guix and Outreachy Date: Thu, 08 Feb 2018 14:47:29 +0100 Message-ID: <874lmrwq32.fsf@gnu.org> References: <87fu6y27re.fsf@elephly.net> <87zi4lg4ep.fsf@elephly.net> <871shxunnf.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejmY4-0007WH-0g for guix-devel@gnu.org; Thu, 08 Feb 2018 08:47:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejmY0-00019u-RY for guix-devel@gnu.org; Thu, 08 Feb 2018 08:47:36 -0500 Received: from hera.aquilenet.fr ([2a0c:e300::1]:48900) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ejmY0-00019C-KJ for guix-devel@gnu.org; Thu, 08 Feb 2018 08:47:32 -0500 In-Reply-To: <871shxunnf.fsf@elephly.net> (Ricardo Wurmus's message of "Wed, 07 Feb 2018 10:58:28 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: Guix-devel Hello, Ricardo Wurmus skribis: >> 3. rewrite more things currently provided by bootstrap binaries in >> guile to reduce our bootsrap binary base. > > This seems good, as it consists of many independent sub-projects. On > the other hand: we already have a couple of implementations that are > just not used in Guix at this point. For example, there are a couple of > Guile implementations of tar out there (I remember Mark H Weaver posted > one some years ago), and there=E2=80=99s even a Bash interpreter out there > (written by Rutger). Yes, I think this lends itself well to an internship because it=E2=80=99s v= ery much a step-by-step project: one could focus on Bash, or on tar, or awk, etc. >> 10. provide user interface to our build farm where we could request >> building a specific package. > > A user interface to the build farm would generally be useful. I don=E2= =80=99t > see how it would keep someone busy for three months, but I think this > proposal is worth fleshing out. Right. Depending on how far we want to go, it could definitely keep someone busy for some time. We could have an HTTP interface allowing users to request a build. That=E2=80=99s not trivial because we=E2=80=99d need authentication, a noti= fication mechanism, and generally giving some thought to the security implications of this. We could also add new monitoring HTTP interfaces that would provide info not available through the existing /api/* interfaces. For instance, having something that would show the build machines used, how well-balanced the load is, and so on. Or generally having ways to browse builds in different ways=E2=80=94by evaluation ID, by commit, by nam= e, etc. Ludo=E2=80=99.