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 08:51:10 +0100 Message-ID: References: <87fu6y27re.fsf@elephly.net> <87zi4lg4ep.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c049e5c081dee05649a8f00" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejKVe-0001xf-EG for guix-devel@gnu.org; Wed, 07 Feb 2018 02:51:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejKVc-0003QC-FZ for guix-devel@gnu.org; Wed, 07 Feb 2018 02:51:14 -0500 Received: from mail-it0-x22e.google.com ([2607:f8b0:4001:c0b::22e]:51082) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ejKVc-0003P9-7Y for guix-devel@gnu.org; Wed, 07 Feb 2018 02:51:12 -0500 Received: by mail-it0-x22e.google.com with SMTP id x128so1180318ite.0 for ; Tue, 06 Feb 2018 23:51:11 -0800 (PST) In-Reply-To: <87zi4lg4ep.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 --94eb2c049e5c081dee05649a8f00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-02-06 23:05 GMT+01:00 Ricardo Wurmus : > Hi Guix, > > some weeks ago I wrote this: > > > on behalf of the Guix community I submitted an application for this > > project to participate in Outreachy, an internship project for people > > from sections of the population that are commonly underrepresented in > > the world of free software development. > > > > Our application is currently undergoing review. If accepted we will > > fund one intern for the upcoming internship period between May and > > August. > > > > The Guix community already has a landing page on the Outreachy website: > > > > https://www.outreachy.org/communities/cfp/gnu-guix/ > > > > You can already submit project proposals on this page, which Ludo and I > > would review and approve. Please consider becoming a co-mentor for a > > project to make our ongoing participation in Outreachy a success. > > > > Feel free to discuss project ideas right here before submitting an > > official proposal. Project ideas for the Google Summer of Code are > > equally valid for an Outreachy internship. > > The application process in which interns pick a community to work with > will start very soon. Before we can be accepted as a participating > community we need to submit at least one project proposal and have > identified and approved a mentor. > > So far we have received one project idea relating to writing a Guile > build system and recovering some of the potluck ideas, and I=E2=80=99d li= ke to > propose another one: > > * User interface improvements > > As a source-based package manager, Guix builds packages from source when > no binaries are available to substitute the local build. The resulting > pages of compiler output can be very disorienting and confusing to > users. The immediate goal of this project is to implement the means to > let Guix direct all build output to a log file in a well-known > directory, and report only the build/installation progress to users. > This should at least be done for =E2=80=9Cguix package=E2=80=9D; =E2=80= =9Cguix build=E2=80=9D may still > print all output by default. Verbosity should be controllable with > command line options. > > As a first task, the intern may want to implement coloured output for > the printing of daemon messages, while leaving the compiler output > unchanged. > > A second tasks could be to modify the daemon to keep logs also for > failed builds. Currently, logs are only kept for successful builds. > > As a next step all output between build phases ought to be hidden by > default. Only the daemon messages announcing the start and completion > of build phases should be printed. > > An extra challenge is to allow for more progress information to be > collected and reported. Cmake, for example, usually reports build > progress as a percentage on each line. Presenting the Cmake percentage > output as a progress bar can be a first step towards this goal. The GNU > build system, however, does not report any progress. The intern could > experiment with ideas to estimate the total number of build steps and > then compute the progress as the build phase is executed. Finally the > progress can be represented as a progress bar. > > This project is composed of smaller tasks that are almost indepedent. > The completion of any of these tasks would give the intern more insight > into how to complete the remaining tasks. The completion of any subset > of these tasks would be a valuable contribution to GNU Guix. > > I would serve as the primary mentor for this project. I=E2=80=99d like t= o > encourage you to volunteer to dedicate some time to support this project > as a co-mentor, which involves attending weekly short online meetings > and providing guidance to the intern. > > What do you think? > > I like this. Some idea also came up at FOSDEM to worth considering. 1. port guix to RISCV - I currently feel I could not mentor this though. 2. write a JVM inmplementation in guile to stabilize our java bootstrap pat= h 3. rewrite more things currently provided by bootstrap binaries in guile to reduce our bootsrap binary base. 4. explore ways to reduce package explosion due to language specific package managers in functional package managers (this also affects nix) - I have a rough idea about this, maybe we could use ddc and depedency rewriting to eliminate unneccesary versions. 5. explore orchestration in guix - I think Chris could be interested in this, and I am also willing to help. 6. explore provisioning in guix - provisioning from cloud provides essentially boils down to talking to apis, but I would be really interested in provisioning bare metal. This is thightly related to orchestration. 7. provide user services, provide dinamically configured idempontent services, service quotas 8. bring more state inside the configuration system: bootloader information, partitioning information, service configuration that is currently state (such as database schemas). 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 this could speed up development on core-updates and feature branches. 10. provide user interface to our build farm where we could request building a specific package. These are now very rough, it is like a brainstorming session. If there is interest in any of these, I can write up some details about what I was thinking. WDYT? - > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > > --94eb2c049e5c081dee05649a8f00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -02-06 23:05 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:=
Hi Guix,

some weeks ago I wrote this:

> on behalf of the Guix community I submitted an application for this > project to participate in Outreachy, an internship project for people<= br> > from sections of the population that are commonly underrepresented in<= br> > the world of free software development.
>
> Our application is currently undergoing review.=C2=A0 If accepted we w= ill
> fund one intern for the upcoming internship period between May and
> August.
>
> The Guix community already has a landing page on the Outreachy website= :
>
>=C2=A0 =C2=A0 =C2=A0https://www.outreachy.org= /communities/cfp/gnu-guix/
>
> You can already submit project proposals on this page, which Ludo and = I
> would review and approve.=C2=A0 Please consider becoming a co-mentor f= or a
> project to make our ongoing participation in Outreachy a success.
>
> Feel free to discuss project ideas right here before submitting an
> official proposal.=C2=A0 Project ideas for the Google Summer of Code a= re
> equally valid for an Outreachy internship.

The application process in which interns pick a community to work wi= th
will start very soon.=C2=A0 Before we can be accepted as a participating community we need to submit at least one project proposal and have
identified and approved a mentor.

So far we have received one project idea relating to writing a Guile
build system and recovering some of the potluck ideas, and I=E2=80=99d like= to
propose another one:

* User interface improvements

As a source-based package manager, Guix builds packages from source when no binaries are available to substitute the local build.=C2=A0 The resultin= g
pages of compiler output can be very disorienting and confusing to
users.=C2=A0 The immediate goal of this project is to implement the means t= o
let Guix direct all build output to a log file in a well-known
directory, and report only the build/installation progress to users.
This should at least be done for =E2=80=9Cguix package=E2=80=9D; =E2=80=9Cg= uix build=E2=80=9D may still
print all output by default.=C2=A0 Verbosity should be controllable with command line options.

As a first task, the intern may want to implement coloured output for
the printing of daemon messages, while leaving the compiler output
unchanged.

A second tasks could be to modify the daemon to keep logs also for
failed builds.=C2=A0 Currently, logs are only kept for successful builds.
As a next step all output between build phases ought to be hidden by
default.=C2=A0 Only the daemon messages announcing the start and completion=
of build phases should be printed.

An extra challenge is to allow for more progress information to be
collected and reported.=C2=A0 Cmake, for example, usually reports build
progress as a percentage on each line.=C2=A0 Presenting the Cmake percentag= e
output as a progress bar can be a first step towards this goal.=C2=A0 The G= NU
build system, however, does not report any progress.=C2=A0 The intern could=
experiment with ideas to estimate the total number of build steps and
then compute the progress as the build phase is executed.=C2=A0 Finally the=
progress can be represented as a progress bar.

This project is composed of smaller tasks that are almost indepedent.
The completion of any of these tasks would give the intern more insight
into how to complete the remaining tasks.=C2=A0 The completion of any subse= t
of these tasks would be a valuable contribution to GNU Guix.

I would serve as the primary mentor for this project.=C2=A0 I=E2=80=99d lik= e to
encourage you to volunteer to dedicate some time to support this project as a co-mentor, which involves attending weekly short online meetings
and providing guidance to the intern.

What do you think?

I= like this.

Some idea also came up at FOSDEM to wo= rth considering.

1. port guix to RISCV - I current= ly feel I could not mentor this though.
2. write a JVM inmplement= ation in guile to stabilize our java bootstrap path
3. rewrite mo= re things currently provided by bootstrap binaries in guile to reduce our b= ootsrap binary base.
4. explore ways to reduce package explosion = due to language specific package managers in functional package managers (t= his also affects nix) - I have a rough idea about this, maybe we could use = ddc and depedency rewriting to eliminate unneccesary versions.
5.= explore orchestration in guix - I think Chris could be interested in this,= and I am also willing to help.
6. explore provisioning in guix -= provisioning from cloud provides essentially boils down to talking to apis= , but I would be really interested in provisioning bare metal. This is thig= htly related to orchestration.
7. provide user services, provide = dinamically configured idempontent services, service quotas
8. br= ing more state inside the configuration system: bootloader information, par= titioning information, service configuration that is currently state (such = as database schemas).
9. get guix publish to work on some solutio= n, that allows us to share pre-built packages outside our local network - I= have a feeling that this could speed up development on core-updates and fe= ature branches.
10. provide user interface to our build farm wher= e we could request building a specific package.

Th= ese are now very rough, it is like a brainstorming session.
If th= ere is interest in any of these, I can write up some details about what I w= as thinking.
WDYT?
-=C2=A0
--
Ricardo

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




--94eb2c049e5c081dee05649a8f00--