Re: Call for project proposals: Guix and Outreachy

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

2018-02-07 10:58 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 4645 bytes --]