2018-02-06 23:05 GMT+01:00 Ricardo Wurmus <rek...@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 > > 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’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 > 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’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. WDYT? - > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > >
