|Subject:||Re: Call for project proposals: Guix and Outreachy|
|Date:||Wed, 7 Feb 2018 08:51:10 +0100|
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
> 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?
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
|[Prev in Thread]||Current Thread||[Next in Thread]|