[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for project proposals: Guix and Outreachy

From: Gábor Boskovits
Subject: Re: Call for project proposals: Guix and Outreachy
Date: Wed, 7 Feb 2018 08:51:10 +0100

2018-02-06 23:05 GMT+01:00 Ricardo Wurmus <address@hidden>:
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:
> 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’d 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.  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 “guix package”; “guix build” 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

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’d like 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 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 path
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.

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC

reply via email to

[Prev in Thread] Current Thread [Next in Thread]