Re: Call for project proposals: Guix and Outreachy

[Gábor Boskovits]

2018-02-07 10:58 GMT+01:00 Ricardo Wurmus <address@hidden>:

Hi Gábor,

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’t 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’s even a Bash interpreter out there
(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 this
> 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’t
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