From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: Call for project proposals: Guix and Outreachy Date: Wed, 7 Feb 2018 11:45:03 +0100 Message-ID: References: <87fu6y27re.fsf@elephly.net> <87zi4lg4ep.fsf@elephly.net> <871shxunnf.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11444d1ae5bfe505649cfc18" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejNDw-00064X-Gy for guix-devel@gnu.org; Wed, 07 Feb 2018 05:45:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejNDv-0006pJ-10 for guix-devel@gnu.org; Wed, 07 Feb 2018 05:45:08 -0500 Received: from mail-io0-x22c.google.com ([2607:f8b0:4001:c06::22c]:42947) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ejNDu-0006oz-Po for guix-devel@gnu.org; Wed, 07 Feb 2018 05:45:06 -0500 Received: by mail-io0-x22c.google.com with SMTP id 25so1507295ioj.9 for ; Wed, 07 Feb 2018 02:45:06 -0800 (PST) In-Reply-To: <871shxunnf.fsf@elephly.net> 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 --001a11444d1ae5bfe505649cfc18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-02-07 10:58 GMT+01:00 Ricardo Wurmus : > > Hi G=C3=A1bor, > > thanks for your ideas. > > > 1. port guix to RISCV - I currently feel I could not mentor this > > though. > > I have a feeling that this may not be suitable for a three-month > internship because we don=E2=80=99t even have the RISC-V toolchain yet. > Building these things takes a long time, so it can be quite discouraging > for a new contributor to work on this. > > Yes, it can be discouraging, though we actually have almost everything needed on core-updates. What I feel, though is that RISCV support is immature in general, moreover hardware capacity is currently lacking/really overpriced. I guess I will have a look at this myself, once the support appears in a glibc we have on core-updates. I take this back from the list of proposals now. > > 2. write a JVM inmplementation in guile to stabilize our java > > bootstrap path > > This is quite a lot of work and not really suited for new contributors. > I like the idea, though, and think that eventually some of us should > give it a try. > I might check this one personally and estimate the effort. I don't feel this should be a generally useful thing, just a bare minimum. I take this back from the list of proposals now. > > > 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 ther= e > (written by Rutger). > > We should include in the proposal to first use the already available implementations, then a next stage could be to reimplement new stuff. WDYT? > > 9. get guix publish to work on some solution, that allows us to share > > pre-built packages outside our local network - I have a feeling that th= is > > could speed up development on core-updates and feature branches. > > Do you mean publishing to GNUnet? > Yes, I do. As far as I understood, we actually have this already working. It's just there are some performance problems, and should be upstreamed. Is this correct? > > > 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. > This is definiately not a three month project, but if we can also gain some inspection capabilities, that would mean a lot more. For example retrieving the build logs, failed trees, stacktraces. This could really help in understanding what is going on, for example in situations we are now having with sablevm. > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > --001a11444d1ae5bfe505649cfc18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -02-07 10:58 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:=

Hi G=C3=A1bor,

thanks for your ideas.

> 1. port guix to RISCV - I currently feel I could not mentor this
> though.

I have a feeling that this may not be suitable for a three-month
internship because we don=E2=80=99t even have the RISC-V toolchain yet.
Building these things takes a long time, so it can be quite discouraging for a new contributor to work on this.

Yes, it can be discouraging, = though we actually have almost everything needed
on core-updates.= What I feel, though is that RISCV support is immature in general,
moreover hardware capacity is currently lacking/really overpriced. I gues= s I will
have a look at this myself, once the support appears in = a glibc we have on core-updates.
I take this back from the list o= f proposals now.
=C2=A0
> 2. write a JVM inmplementation in guile to stabilize our java
> bootstrap path

This is quite a lot of work and not really suited for new contributo= rs.
I like the idea, though, and think that eventually some of us should
give it a try.

I might check this one p= ersonally and estimate the effort. I don't feel
this should b= e a generally useful thing, just a bare minimum. I take this back
from the list of proposals now.=C2=A0

> 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.=C2= =A0 On
the other hand: we already have a couple of implementations that are
just not used in Guix at this point.=C2=A0 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<= br> (written by Rutger).

We should include in the prop= osal to first use the already available implementations,
then a n= ext stage could be to reimplement new stuff. WDYT?
=C2=A0
> 9. get guix publish to work on some solution, that allows us to share<= br> > pre-built packages outside our local network - I have a feeling that t= his
> could speed up development on core-updates and feature branches.

Do you mean publishing to GNUnet?

Yes, I do.

As far as I understood, we actually h= ave this already working. It's just there are some
performanc= e problems, and should be upstreamed. Is this correct?=C2=A0

> 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.=C2=A0 = I don=E2=80=99t
see how it would keep someone busy for three months, but I think this
proposal is worth fleshing out.

This is= definiately not a three month project, but if we can also gain some inspec= tion capabilities,
that would mean a lot more. For example retrie= ving the build logs, failed trees, stacktraces.
This could really= help in understanding what is going on, for example in situations we are n= ow having
with sablevm.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net



--001a11444d1ae5bfe505649cfc18--