Call for project proposals: Guix and Outreachy

Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

Hi Guix,

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.

Thanks in advance for your support!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hi Ricardo,

Ricardo Wurmus writes:

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

This is great news — well done for taking the initiative.

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

I have read through the documentation and I believe I would be able to
commit to the duties of being a mentor / co-mentor.

I would be happy to send more details of where I believe my relative
strengths and weaknesses in this project would be.  I couldn't see an
appropriate place for that on the outreachy website — would it be best
to discuss this by email with you two?  Or on list?

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

Wrt to project ideas, if I understand the target audience right, I would
propose perhaps as one project a strengthening of the Guile tooling
around Guix.

Starter tasks could be helping to package and review existing packages
of Guile software for Guix.

Actual project tasks could revolve around developing a nice Guile build
system for Guix.

First steps would be perhaps to enhance the gnu-build-system with
additional phases for Guile specific tasks (setting the Guile site path
correctly, ensuring guile dependencies are propagated inputs…)

A second step might be a simplified Guile build system, which does not
rely on autotools infrastructure.  I believe this was discussed in the
past: it would be a "beginners build system" for *Guile only* packages
for quick and easy sharing in the Guix community.

Finally we might look at first steps to generate guix package recipes
from guile projects.  A first step might be a well-defined script that
generates a new project filetree, and writes a guix.scm file within it
that contains a Guix recipe using the beginners guile build system.

What do you think?

Alex

Re: Call for project proposals: Guix and Outreachy

[pelzflorian (Florian Pelz)]

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

Hello,

On Fri, Jan 26, 2018 at 12:53:37PM +0100, Alex Sassmannshausen wrote:
> A second step might be a simplified Guile build system, which does not
> rely on autotools infrastructure.  I believe this was discussed in the
> past: it would be a "beginners build system" for *Guile only* packages
> for quick and easy sharing in the Guix community.
> 

By beginners build system, do you mean a Guix build system that just
copies the modules directory and compiles?

Forgive my ignorance as someone who has no deep understanding of
Guile/Guix, but I think it would be better if even simple Guile only
packages used a build system like Meson or Autotools.  Even Guile only
packages should not need Guix or manual copying.  The syntax of
Autotools is too complicated IMHO, but using a general purpose build
system like Meson for simple C projects is no more work than listing
the source files and data files like pkg-config and this should apply
to Guile projects as well.

That said, a beginners Guix build system for pure Guile projects is
done much more easily than making simple general purpose build systems
support Guile.  I’d like to take a look at Meson support for Guile and
Guile implementations of Ninja and Meson, but I probably can’t/won’t
commit the time…  Well maybe…

Regards,
Florian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hi

pelzflorian (Florian Pelz) writes:

> Hello,
>
> On Fri, Jan 26, 2018 at 12:53:37PM +0100, Alex Sassmannshausen wrote:
>> A second step might be a simplified Guile build system, which does not
>> rely on autotools infrastructure.  I believe this was discussed in the
>> past: it would be a "beginners build system" for *Guile only* packages
>> for quick and easy sharing in the Guix community.
>
> By beginners build system, do you mean a Guix build system that just
> copies the modules directory and compiles?

Yes — it would just carry out the steps so that if the Guile package is
a propagated input to anything else, or if it is installed directly, the
Guile package would be available to the Guile executable in that
context.

So the files would simply be installed in the ACTUAL_GUILE_VERSION site
dir & ccache dir.

> Forgive my ignorance as someone who has no deep understanding of
> Guile/Guix, but I think it would be better if even simple Guile only
> packages used a build system like Meson or Autotools.  Even Guile only
> packages should not need Guix or manual copying.  The syntax of
> Autotools is too complicated IMHO, but using a general purpose build
> system like Meson for simple C projects is no more work than listing
> the source files and data files like pkg-config and this should apply
> to Guile projects as well.

I sympathise with your perspective, but this proposed second step would
be quite "selfish" from the perspective of Guix and Guile: it would be a
strong improvement in comparison to what we have now (no widely used
package manager, or project bootstrapping system for Guile), whilst not
committing to infrastructure behind it.

As such it doesn't aim to "care" about non-guix use-cases.  To phrase it
strongly I think Guix is the de-facto Guile package manager, so a good
first step is a simple build environment for that specific package
manager.

We could then gradually build on the tooling to allow a migration path
to autotools.

> That said, a beginners Guix build system for pure Guile projects is
> done much more easily than making simple general purpose build systems
> support Guile.  I’d like to take a look at Meson support for Guile and
> Guile implementations of Ninja and Meson, but I probably can’t/won’t
> commit the time…  Well maybe…

I would be very interested to hear about your further research into this
area for sure! The above stuff is just my opinion so far :-)

Cheers,
Alex

Re: Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

Hi Alex,

> I have read through the documentation and I believe I would be able to
> commit to the duties of being a mentor / co-mentor.

Wonderful!

> I would be happy to send more details of where I believe my relative
> strengths and weaknesses in this project would be.  I couldn't see an
> appropriate place for that on the outreachy website — would it be best
> to discuss this by email with you two?  Or on list?

Either way is fine.  You’re welcome to send me email off-list if you
think it shouldn’t be public.

>> 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.
>
> Wrt to project ideas, if I understand the target audience right, I would
> propose perhaps as one project a strengthening of the Guile tooling
> around Guix.
>
> Starter tasks could be helping to package and review existing packages
> of Guile software for Guix.
>
> Actual project tasks could revolve around developing a nice Guile build
> system for Guix.

Thank you for this proposal.

I wonder if that’s a project that would be big enough for a three month
internship.  Adding support for existing build systems in Guix usually
isn’t very difficult, because much of the work has already been done in
the form of the gnu-build-system.

I worry that the actual implementation would be little more than walking
down the directory tree, compiling every Scheme file, and then copying
files over to a target location.

On the other hand, this project could become more comprehensive if we
looked at the earlier potluck proposal and adopted a few more tasks from
there.  What do you think?

> First steps would be perhaps to enhance the gnu-build-system with
> additional phases for Guile specific tasks (setting the Guile site path
> correctly, ensuring guile dependencies are propagated inputs…)
>
> A second step might be a simplified Guile build system, which does not
> rely on autotools infrastructure.  I believe this was discussed in the
> past: it would be a "beginners build system" for *Guile only* packages
> for quick and easy sharing in the Guix community.

These seem like reasonable steps.  What are the assumptions that we
would make about Guile-only projects?  It might help to have a list of
Guile packages that don’t use a proper build system and compare their
file layout to figure out the kind of work the build system would have
to perform.

> Finally we might look at first steps to generate guix package recipes
> from guile projects.  A first step might be a well-defined script that
> generates a new project filetree, and writes a guix.scm file within it
> that contains a Guix recipe using the beginners guile build system.

Would this still be needed even if the guile-build-system were robust
enough to deal with different kinds of file layouts?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hey,

Ricardo Wurmus writes:

> Hi Alex,
>
>> I have read through the documentation and I believe I would be able to
>> commit to the duties of being a mentor / co-mentor.
>
> Wonderful!
>
>> I would be happy to send more details of where I believe my relative
>> strengths and weaknesses in this project would be.  I couldn't see an
>> appropriate place for that on the outreachy website — would it be best
>> to discuss this by email with you two?  Or on list?
>
> Either way is fine.  You’re welcome to send me email off-list if you
> think it shouldn’t be public.

OK, will do!

>>> 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.
>>
>> Wrt to project ideas, if I understand the target audience right, I would
>> propose perhaps as one project a strengthening of the Guile tooling
>> around Guix.
>>
>> Starter tasks could be helping to package and review existing packages
>> of Guile software for Guix.
>>
>> Actual project tasks could revolve around developing a nice Guile build
>> system for Guix.
>
> Thank you for this proposal.
>
> I wonder if that’s a project that would be big enough for a three month
> internship.  Adding support for existing build systems in Guix usually
> isn’t very difficult, because much of the work has already been done in
> the form of the gnu-build-system.
>
> I worry that the actual implementation would be little more than walking
> down the directory tree, compiling every Scheme file, and then copying
> files over to a target location.
>
> On the other hand, this project could become more comprehensive if we
> looked at the earlier potluck proposal and adopted a few more tasks from
> there.  What do you think?

I like this idea.  It feels like we'd have a nice learning curve here,
that also touches a significant chunk of guix build tooling here.

So:
- pre-project tasks: package Guile (and other) packages, to get familiar
  with problems around packaging, and basic concepts.
- project 1): extend gnu-build-system for a guile-build-system that
  "does the right thing", when full autotools support is present in the
  project. [difficulty: easy: just customise/add gnu-build-system
  phase].
- project 2): simple-guile-build-system that installs guile only modules
  without autotools present. [difficulty: medium: write a build-system
  from scratch]
- project 3) and onward: potluck.  This project would take the candidate
  beyond the confines of Guile projects specifically, focusing on the
  user journey of "new contributors" to Guix in general.  The work
  optimising for Guile, and their own user journey, should be
  informative for this. [difficulty: ?]

The latter will need to be broken down further: ideally we want to be
able to present a well-defined project with discrete steps that could be
added to Guix incrementally to avoid a large chunk of code outside
master to be merged "at some point…"

>> First steps would be perhaps to enhance the gnu-build-system with
>> additional phases for Guile specific tasks (setting the Guile site path
>> correctly, ensuring guile dependencies are propagated inputs…)
>>
>> A second step might be a simplified Guile build system, which does not
>> rely on autotools infrastructure.  I believe this was discussed in the
>> past: it would be a "beginners build system" for *Guile only* packages
>> for quick and easy sharing in the Guix community.
>
> These seem like reasonable steps.  What are the assumptions that we
> would make about Guile-only projects?  It might help to have a list of
> Guile packages that don’t use a proper build system and compare their
> file layout to figure out the kind of work the build system would have
> to perform.

Agreed.  I think the following assumptions are fairly uncontroversial:
- a guile project has at least one source file
- but no more than one source file in the "root" of the modules
  directory layout
- if the project has more than one source file, these are located in
  subdirectories of the "root" of the modules directory layout
- there should be a directory of .scm files that contains tests,
  generally called "tests"
- there could be a directory containing .texi files, generally called
  "doc"

e.g.
foo-project/foo.scm
foo-project/foo/bar.scm
foo-project/foo/baz.scm
foo-project/fan/bot.scm
foo-project/tests/....scm
foo-project/doc/....texi

But as you say, it probably makes more sense looking at existing
Guile-only projects to confirm/falsify this.

>> Finally we might look at first steps to generate guix package recipes
>> from guile projects.  A first step might be a well-defined script that
>> generates a new project filetree, and writes a guix.scm file within it
>> that contains a Guix recipe using the beginners guile build system.
>
> Would this still be needed even if the guile-build-system were robust
> enough to deal with different kinds of file layouts?

You are right — this may not be necessary.  Additionally, if we progress
down the potluck road, then that might provide a more general tool for
this.

Alex

Re: Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

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?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Gábor Boskovits]

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

2018-02-06 23:05 GMT+01:00 Ricardo Wurmus <rekado@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
>
>
>
>

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

Re: Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

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.

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

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

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

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

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Gábor Boskovits]

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

Re: Call for project proposals: Guix and Outreachy

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

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

Yes, I think this lends itself well to an internship because it’s very
much a step-by-step project: one could focus on Bash, or on tar, or awk,
etc.

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

Right.  Depending on how far we want to go, it could definitely keep
someone busy for some time.

We could have an HTTP interface allowing users to request a build.
That’s not trivial because we’d need authentication, a notification
mechanism, and generally giving some thought to the security
implications of this.

We could also add new monitoring HTTP interfaces that would provide info
not available through the existing /api/* interfaces.  For instance,
having something that would show the build machines used, how
well-balanced the load is, and so on.  Or generally having ways to
browse builds in different ways—by evaluation ID, by commit, by name,
etc.

Ludo’.

Re: Call for project proposals: Guix and Outreachy

[Andreas Enge]

Hello Gábor,

quite a list of interesting ideas!

On Wed, Feb 07, 2018 at 08:51:10AM +0100, Gábor Boskovits wrote:
> 10. provide user interface to our build farm where we could request building a
> specific package.

This is one specific feature, but could be framed into a more general
project of creating a web frontend to cuirass, with a number of subtasks
(one thing that we use a lot on hydra: with one click, restart the build
of all packages that failed previously).

As in Ricardo's suggestion, this would appeal to diverse competences,
in guile, javascript, databases and interface design. So I think something
interesting and useful would certainly come out of it.

Andreas

Re: Call for project proposals: Guix and Outreachy

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> quite a list of interesting ideas!
>
> On Wed, Feb 07, 2018 at 08:51:10AM +0100, Gábor Boskovits wrote:
>> 10. provide user interface to our build farm where we could request building a
>> specific package.
>
> This is one specific feature, but could be framed into a more general
> project of creating a web frontend to cuirass, with a number of subtasks
> (one thing that we use a lot on hydra: with one click, restart the build
> of all packages that failed previously).
>
> As in Ricardo's suggestion, this would appeal to diverse competences,
> in guile, javascript, databases and interface design. So I think something
> interesting and useful would certainly come out of it.

Agreed!  Actually one thing is adding more /api/* HTTP entry points.
Another one is writing the Web frontend.  Each of these could be a
project on its own, I think.

Thoughts?

Ricardo, should we draft something on this topic?

Ludo’.

Re: Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Andreas Enge <andreas@enge.fr> skribis:
>
>> quite a list of interesting ideas!
>>
>> On Wed, Feb 07, 2018 at 08:51:10AM +0100, Gábor Boskovits wrote:
>>> 10. provide user interface to our build farm where we could request building a
>>> specific package.
>>
>> This is one specific feature, but could be framed into a more general
>> project of creating a web frontend to cuirass, with a number of subtasks
>> (one thing that we use a lot on hydra: with one click, restart the build
>> of all packages that failed previously).
>>
>> As in Ricardo's suggestion, this would appeal to diverse competences,
>> in guile, javascript, databases and interface design. So I think something
>> interesting and useful would certainly come out of it.
>
> Agreed!  Actually one thing is adding more /api/* HTTP entry points.
> Another one is writing the Web frontend.  Each of these could be a
> project on its own, I think.
>
> Thoughts?
>
> Ricardo, should we draft something on this topic?

Our problem at this point is to recruit mentors.  Whoever submits the
project proposal on the Outreachy website[1] applies to become a mentor.
This is then either approved or declined by Ludovic or myself.

The project idea sounds good, but we really need a mentor who feels
responsible for this project and who will be able to guide an intern
throughout the application phase and the three-month internship between
from May to August.

I would be very happy if someone who is willing to oversee this project
would write a draft and submit it on the Outreachy website[1].

I volunteer to be a co-mentor for when the main mentor needs a free
weekend or something like that, but I can only assist, not lead the
project.

[1]: https://www.outreachy.org/communities/cfp/gnu-guix/submit-project/

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Gábor Boskovits]

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

2018-02-08 17:23 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> > Andreas Enge <andreas@enge.fr> skribis:
> >
> >> quite a list of interesting ideas!
> >>
> >> On Wed, Feb 07, 2018 at 08:51:10AM +0100, Gábor Boskovits wrote:
> >>> 10. provide user interface to our build farm where we could request
> building a
> >>> specific package.
> >>
> >> This is one specific feature, but could be framed into a more general
> >> project of creating a web frontend to cuirass, with a number of subtasks
> >> (one thing that we use a lot on hydra: with one click, restart the build
> >> of all packages that failed previously).
> >>
> >> As in Ricardo's suggestion, this would appeal to diverse competences,
> >> in guile, javascript, databases and interface design. So I think
> something
> >> interesting and useful would certainly come out of it.
> >
> > Agreed!  Actually one thing is adding more /api/* HTTP entry points.
> > Another one is writing the Web frontend.  Each of these could be a
> > project on its own, I think.
> >
> > Thoughts?
> >
> > Ricardo, should we draft something on this topic?
>
> Our problem at this point is to recruit mentors.  Whoever submits the
> project proposal on the Outreachy website[1] applies to become a mentor.
> This is then either approved or declined by Ludovic or myself.
>
> The project idea sounds good, but we really need a mentor who feels
> responsible for this project and who will be able to guide an intern
> throughout the application phase and the three-month internship between
> from May to August.
>
> I would be very happy if someone who is willing to oversee this project
> would write a draft and submit it on the Outreachy website[1].
>
> I volunteer to be a co-mentor for when the main mentor needs a free
> weekend or something like that, but I can only assist, not lead the
> project.
>
> [1]: https://www.outreachy.org/communities/cfp/gnu-guix/submit-project/
>
> If we could draft the specifics of this, what we expect as a outcome at
least,
then I am willing to help in mentoring, if that suits you. I might drop
some parts
of the draft if I don't feel comfortable with some parts of the draft
proposed. However
I feel, that the expectations about this should be discussed publicly, to
have a tool
that is really useful for the community, WDYT?

> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

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

Re: Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

Gábor Boskovits <boskovits@gmail.com> writes:

>> The project idea sounds good, but we really need a mentor who feels
>> responsible for this project and who will be able to guide an intern
>> throughout the application phase and the three-month internship between
>> from May to August.
[…]

> If we could draft the specifics of this, what we expect as a outcome
> at least, then I am willing to help in mentoring, if that suits you. I
> might drop some parts of the draft if I don't feel comfortable with
> some parts of the draft proposed.

Thank you.

> However I feel, that the expectations about this should be discussed
> publicly, to have a tool that is really useful for the community,
> WDYT?

Yes, we should discuss this here, but we don’t have all that much time
left before the intern application process begins.  During that period
interns get to pick a project they are interested in and start getting
to know the community.  At the end of the application period we need to
pick one of the applicants.

So even though the internships won’t start before May, we really need to
submit our proposals this week or early next week.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Gábor Boskovits]

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

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

>
> Gábor Boskovits <boskovits@gmail.com> writes:
>
> >> The project idea sounds good, but we really need a mentor who feels
> >> responsible for this project and who will be able to guide an intern
> >> throughout the application phase and the three-month internship between
> >> from May to August.
> […]
>
> > If we could draft the specifics of this, what we expect as a outcome
> > at least, then I am willing to help in mentoring, if that suits you. I
> > might drop some parts of the draft if I don't feel comfortable with
> > some parts of the draft proposed.
>
> Thank you.
>
> > However I feel, that the expectations about this should be discussed
> > publicly, to have a tool that is really useful for the community,
> > WDYT?
>
> Yes, we should discuss this here, but we don’t have all that much time
> left before the intern application process begins.  During that period
> interns get to pick a project they are interested in and start getting
> to know the community.  At the end of the application period we need to
> pick one of the applicants.
>
> So even though the internships won’t start before May, we really need to
> submit our proposals this week or early next week.
>
>
Ok, I've thought about what my personal needs would be at first.
I currently see three main aspects of this user interface:

1. statistics overall
a. percentage of packages failing on a branch (with links)
b. percentage of packages not reproducible (also with links) (can be
interesting in the face of the content addressable store idea, but would be
useful in general)

2. packages, that we tried to build:
a. build status on achitectures
b. build logs
c. related bugs - can this be done easily?
d. related build jobs

3. packages, that we would like to build
a. estimated effort to do so
b. privilege system to do it
c. notification when a build completes
d. some way to make this useful for collaborations - (for example if a
bunch of developers is working on a feature branch, and the feel, that it
is ok to build it, then somehow sum the resources allowable?)

I am not very familiar with our current frontend yet, so if I have
something, that is already done, please note me.

If you have any other suggestions, that would be fine.



> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

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

Re: Call for project proposals: Guix and Outreachy

[Chris Marusich]

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

Gábor Boskovits <boskovits@gmail.com> writes:

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

I am interested in these things, but I am not sure it would be a good
intern project.  Maybe I'm just being sheepish, but since we don't even
have consensus yet on a design for this, I worry that it might not be
fair to ask an intern to take this on at this time.

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

I know you meant GNUnet, but what about publication over mDNS?  That
would be super nice, but I don't know how complicated it would be.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Call for project proposals: Guix and Outreachy

[Gábor Boskovits]

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

2018-02-10 4:06 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
> > 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.
>
> I am interested in these things, but I am not sure it would be a good
> intern project.  Maybe I'm just being sheepish, but since we don't even
> have consensus yet on a design for this, I worry that it might not be
> fair to ask an intern to take this on at this time.
>
> > 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.
>
> I know you meant GNUnet, but what about publication over mDNS?  That
> would be super nice, but I don't know how complicated it would be.


There was some idea that this could also be done using ipfs. Actually this
was just an idea, that would be nice to have, and I think I am open to
suggestions how this should work. It turned out on the guix event, that
we already have a working solution, we might have more knowhow lingering...
I do not feel that I could mentor this though.


> --
> Chris
>

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

Re: Call for project proposals: Guix and Outreachy

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
>> 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.
>
> I am interested in these things, but I am not sure it would be a good
> intern project.  Maybe I'm just being sheepish, but since we don't even
> have consensus yet on a design for this, I worry that it might not be
> fair to ask an intern to take this on at this time.

I agree.  We cannot expect an intern to help us sort our thoughts *and*
implement something in this short internship period.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Call for project proposals: Guix and Outreachy

[Andreas Enge]

Hello Ricardo,

On Tue, Feb 06, 2018 at 11:05:34PM +0100, Ricardo Wurmus wrote:
> * User interface improvements

your project sounds very interesting, it has some technical components,
but might also attract some more diverse talents with its focus on more
general usability. I also like that you identified a progression of different
tasks. All in all, it sounds easier than previous GSoC topics, but that may
also mean that the chances of success are higher, in particular since there
are intermediate milestones that would already add useful things.

Andreas