Re: Code of Conduct and Diversity Statement

[swedebugia]

Hi

On May 13, 2018 2:27:22 AM GMT+02:00, Tonton  wrote:
>Hi,
>
... 
> should we make the CoC more prominent or
>somehow
>inform about it better? For example by putting it or a link to it in
>the topic
>of the IRC channel, as it's own page on the website, if possible as
>part of
>the welcome message to the mailing lists, others?

Yes I think so. I like you proposals. I knew we had one and found it via the 
manual. 

>
>A second question is, the contributor covenant has evolved, should we
>upgrade
>ours from 1.3.0 to the current
>[1.4.0](https://www.contributor-covenant.org/version/1/4/code-of-conduct)?

This community does not really have any maintainers or formal leadership to my 
knowledge. 
How to handle reporting in our case could be handled by here by vote appointing 
a person to handle such issues (for example as a mediator like in 
https://www.noisebridge.net/wiki/Conflict_Resolution) 

>Would like to say that this is probably the best informatics community
>I've
>been part of and the reason I'm bringing it up is to make a statement
>that we
>care, and to make it easier for outsiders and potential participants to
>see
>that this is in fact part of our backbone. I'm so often positively
>surprised
>by the quality of communication here.

I agree. Conflicts here seem rare and to my knowledge well handled when they do.

Cheers
Swedebugia 

Re: Code of Conduct and Diversity Statement

[Nils Gillmann]

swedebugia transcribed 1.7K bytes:
> Hi
> 
> On May 13, 2018 2:27:22 AM GMT+02:00, Tonton  wrote:
> >Hi,
> >
> ... 
> > should we make the CoC more prominent or
> >somehow
> >inform about it better? For example by putting it or a link to it in
> >the topic
> >of the IRC channel, as it's own page on the website, if possible as
> >part of
> >the welcome message to the mailing lists, others?
> 
> Yes I think so. I like you proposals. I knew we had one and found it via the 
> manual. 
> 
> >
> >A second question is, the contributor covenant has evolved, should we
> >upgrade
> >ours from 1.3.0 to the current
> >[1.4.0](https://www.contributor-covenant.org/version/1/4/code-of-conduct)?
> 
> This community does not really have any maintainers or formal leadership to 
> my knowledge. 
> How to handle reporting in our case could be handled by here by vote 
> appointing a person to handle such issues (for example as a mediator like in 
> https://www.noisebridge.net/wiki/Conflict_Resolution) 

Here's another group working on "Guidelines for Moderators of Coexistence".
Their document is well-written and now translated in 3 languages:

https://structure.pages.de/convivenza.en

> >Would like to say that this is probably the best informatics community
> >I've
> >been part of and the reason I'm bringing it up is to make a statement
> >that we
> >care, and to make it easier for outsiders and potential participants to
> >see
> >that this is in fact part of our backbone. I'm so often positively
> >surprised
> >by the quality of communication here.
> 
> I agree. Conflicts here seem rare and to my knowledge well handled when they 
> do.
> 
> Cheers
> Swedebugia 

Re: Code of Conduct and Diversity Statement

[Pierre Neidhardt]

From: 
https://www.recurse.com/blog/83-michael-nielsen-joins-the-recurse-center-to-help-build-a-research-lab

> To give some flavor for the types of work we’re excited by, here’s a
> small sampling of things that inspire us: [...] Systems Software
> Research is Irrelevant[1] [...]

I've read this paper (it's rather short) and as the title suggests, it
arguments over why there won't be anything new in research and that Unix
is "good enough".

This was 2000 and maybe there was nothing better, but in my opinion it
does not make those statements any less fallacious: Unix had issues
(people have written entire books[2] about it) and claiming to know to
where research is going to end is somewhat arrogant, isn't it?

And see, in 2008 Eelco Dolstra publishes the seminal paper "NixOS: A
Purely Functional Linux Distribution"[3], which proved Rob Pike awfully
wrong.

Anyways, saying all that because while Recurse looks great, it's sad
that their research initiative doesn't seem to believe in NixOS / GuixSD
:( Or did I get it wrong?

[1]: http://doc.cat-v.org/bell_labs/utah2000/utah2000.html

[2]: http://web.mit.edu/%7Esimsong/www/ugh.pdf

[3]: https://nixos.org/~eelco/pubs/nixos-icfp2008-final.pdf

--
Pierre Neidhardt

What one fool can do, another can.
-- Ancient Simian Proverb


signature.asc
Description: PGP signature

Re: [rb-general] Paper preprint: Reproducible genomics analysis pipelines with GNU Guix

[Ricardo Wurmus]

Catonano  writes:

> Ricardo, I don't understand the problem you're raising here (I didn't read
> the article yet, though)
>
> Would you mind to elaborate on that ?
>
> Why would you want to record the environment ?

I want to record the detected build environment so that I can restore it
at execution time.  Autoconf provides macros that probe the environment
and record the full path to detected tools.  For example, I’m looking
for Samtools, and the user may provide a particular variant of Samtools
at configure time.  I record the full path to the executable at
configure time and embed that path in a configuration file that is read
when the pipeline is run.

This works fine for tools, but doesn’t work very well at all for modules
in language environments.  Take R for example.  I can detect and record
the location of the R and Rscript executables, but I cannot easily
record the location of build-time R packages (such as r-deseq2) in a way
that allows me to rebuild the environment at runtime.

Instead of writing an Autoconf macro that records the exact location of
each of the detected R packages and their dependencies I chose to solve
the problem in Guix by wrapping the pipeline executables in R_SITE_LIBS,
because I figured that on systems without Guix you aren’t likely to
install R packages into separate unique locations anyway — on most
systems R packages end up being installed to one and the same directory.

I think the desire to restore the configured environment at runtime is
valid and we do this all the time when we run binaries that have
embedded absolute paths (to libraries or other tools).  It’s just that
it gets pretty awkward to do this for things like R packages or Python
modules (or Guile modules for that matter).

The Guix workflow language solves this problem by depending on Guix for
software deployment.  For PiGx we picked Snakemake early on and it does
not have a software deployment solution (it expects to either run inside
a suitable environment that the user provides or to have access to
pre-built Singularity application bundles).  I don’t like to treat
pipelines like some sort of collection of scripts that must be invoked
in a suitable environment.  I like to see pipelines as big software
packages that should know about the environment they need, that can be
configured like regular tools, and thus only require the packager to
assemble the environment, not the end-user.

--
Ricardo

Re: [rb-general] Paper preprint: Reproducible genomics analysis pipelines with GNU Guix

[Catonano]

2018-05-13 7:07 GMT+02:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> > Ricardo, I don't understand the problem you're raising here (I didn't
> read
> > the article yet, though)
> >
> > Would you mind to elaborate on that ?
> >
> > Why would you want to record the environment ?
>
> I want to record the detected build environment so that I can restore it
> at execution time.  Autoconf provides macros that probe the environment
> and record the full path to detected tools.  For example, I’m looking
> for Samtools, and the user may provide a particular variant of Samtools
> at configure time.


Thanks for clarifying !

Let me vent some thoughts on te issue !

Under Guix, the way to provide a specific version of the Samtools would be
to run the configuration in an environment that offers a specific Samtools
package, so that the configuration tool can pick that up

Under a traditional distro, it'd be to feed file paths to the configuration
tool

So, how much of the traditional way of doing things do we want to support,
in our pipelines ?

I record the full path to the executable at
> configure time and embed that path in a configuration file that is read
> when the pipeline is run.
>
> This works fine for tools, but doesn’t work very well at all for modules
> in language environments.  Take R for example.  I can detect and record
> the location of the R and Rscript executables, but I cannot easily
> record the location of build-time R packages (such as r-deseq2) in a way
> that allows me to rebuild the environment at runtime.
>
> Instead of writing an Autoconf macro that records the exact location of
> each of the detected R packages and their dependencies I chose to solve
> the problem in Guix by wrapping the pipeline executables in R_SITE_LIBS,
> because I figured that on systems without Guix you aren’t likely to
> install R packages into separate unique locations anyway — on most
> systems R packages end up being installed to one and the same directory.
>
> I think the desire to restore the configured environment at runtime is
> valid and we do this all the time when we run binaries that have
> embedded absolute paths (to libraries or other tools).


I didn't mean to imply it's not valid
I was just trying to understand what are the concerns on the ground and the
context



> It’s just that
> it gets pretty awkward to do this for things like R packages or Python
> modules (or Guile modules for that matter).
>
> The Guix workflow language solves this problem by depending on Guix for
> software deployment.  For PiGx we picked Snakemake early on and it does
> not have a software deployment solution (it expects to either run inside
> a suitable environment that the user provides or to have access to
> pre-built Singularity application bundles).  I don’t like to treat
> pipelines like some sort of collection of scripts that must be invoked
> in a suitable environment.  I like to see pipelines as big software
> packages that should know about the environment they need, that can be
> configured like regular tools, and thus only require the packager to
> assemble the environment, not the end-user.
>

I understand your concern to consider pipelines as packages

But say, for example, that a pipeline gets distributed as a .deb package
with dependencies to R (or Guile) modules

Or, say, that a pipeline is distributed with a bundled guix.scm file
containing R modules (or Guile modules) as inputs

Would that break the idea of a pipeline as a package ?

I'm afraid that the idea of a pipeline as a package shouldn't be entrusted
to the configuration tool, but rather to the package management tool

And the pipeline author shouldn't be assumed to work in isolation,
confident that any package management environment will be able to rus their
pipeline smoothly

The pipelines authors should be concerned with the collocation of their
pipeline in the packaged graph, that shouldn't be a concern of the packager
only

Maybe the sotware authors should provide dependency information in a
standardized format (rdf ? ) and that should be leveraged by packagers in
order to prepare .deb packages or guix.scm files

And if you are a developer and you want to test the software with a
specific version of a dependency, then you should run the configuration
tool in an environment where that version of the dependency is available,
so that the configuration tool can pick that up

If you are on Guix, you will probably create that environment with the Guix
environment tool

If you are on Debian or Fedora, you will have to rely on those distros
development tools



On traditional distros, you can install packages in your user folder or in
/opt or in other positions

And then, you can feed those to the configuration tool

On Guix, the conditions are different

The idea of pipelines as packages will be treated differently by the
configuration tool under Guix and the configuration tool under Debian/Fedora

So, in my view a configuration tool should be quite

Re: a GUIX_PACKAGE_PATH / modules puzzle

[Ricardo Wurmus]

Nils Gillmann  writes:

>> If you have a file “core/lang-perl/perl.scm” and the module is called
>> “(core lang-perl perl)” then you should not have “core” itself on
>> GUIX_PACKAGE_PATH but its parent directory.
>
> In my example (pkgs lang-perl perl) itself had the parent directory "pkgs".
> I admit, code examples would've made it more clear..
>
> Since we can point to github.com regularly, I think my private server would
> not be considered problematic?

It is better to provide a minimal example that demonstrates the
problem.  This is better than providing a full repository and ask other
people to figure out what is relevant and what is not.

-- 
Ricardo

Resources around inclusion, diversity, conduct and harrasment (was Re: Code of Conduct and Diversity Statement)

[Tonton]

Hi,

Here is a bunch of curated links on the topic from what I've found the last
week or so with binge-reading/research. I'm adding short descriptions to some
were the link itself is not explanatory. Trying to put them in order of "value
for time" and usefulness for us, as a free software community.

An outstanding resource, that unfortunately requires physical presence, is
the ally skills workshops, if you ever have the chance - take it.
https://adainitiative.org/continue-our-work/workshops-and-training/
https://frameshiftconsulting.com/ally-skills-workshop/

__TRIGGER WARNING__
Some of these articles will contain more or less explicit retellings or
examples of Bad-Behaviour(TM). These articles are marked with '#TW#', and most
(if not all) have a warning from the author before the text itself.

https://modelviewculture.com/pieces/a-code-of-conduct-is-not-enough

https://www.recurse.com/manual#sec-environment
See also the sections 'struggling' and 'mental health'.

https://modelviewculture.com/pieces/ten-lessons-learned-from-organizing-diversity-focused-events

https://hypatia.ca/2017/07/18/the-al-capone-theory-of-sexual-harassment/

#TW# https://hypatia.ca/2016/06/21/no-more-rock-stars/
How to not have "rock stars" with too much social influence in a group. But
also has loads of general guidelines for making safer spaces.

https://hypatia.ca/safety/
On speaking out and safety for those thinking about speaking out.

http://www.slate.com/articles/news_and_politics/jurisprudence/2013/06/why_cops_don_t_believe_rape_victims_and_how_brain_science_can_solve_the.html

#TW#
https://medium.com/@FoldableHuman/gamergate-and-base-assumptions-transcript-ab8f91074ad7

#TW# https://hypatia.ca/2014/08/05/what-you-can-do/

#TW# http://pervocracy.blogspot.com.es/2012/06/missing-stair.html
Something to watch out for. Explanation of a term.

http://geekfeminism.wikia.com/wiki/Community_anti-harassment
http://geekfeminism.wikia.com/wiki/Diversity_statement
https://geekfeminism.org/about/code-of-conduct/
The geekfeminism wiki is a great resource for topics generally in the area of
inclusion, diversity and harrasment. These are specifically on code of
conduct and similar.

https://www.reddit.com/r/rust/comments/6ewjt5/question_about_rusts_odd_code_of_conduct/dif1xvb/
https://www.reddit.com/r/rust/comments/6ewjt5/question_about_rusts_odd_code_of_conduct/
First of these two is a response far into one of the subthreads by user
graydon2 (from other responses seems like a previous core maintainer or
similar of rust). This discussion brings the gray very well into the
discussion.

https://hypatia.ca/2017/03/21/but-is-it-systemic/

At this point we are getting into specific cases, more details, and more work
necessary for analysis and understanding.

#TW#
https://milenapopova.eu/2016/06/rape-sexual-assault-ioerror-tor-and-encouraging-victims-to-report-rape-to-law-enforcement.html

#TW# https://blog.patternsinthevoid.net/the-forest-for-the-trees.html

#TW# https://hypatia.ca/2016/06/07/he-said-they-said/


pgpka1fBQrlVD.pgp
Description: OpenPGP digital signature

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Tatiana Sholokhova]

Hi all,

Thank you for your help and the provided resources which are very useful
for me at the first stage of the project.

I have built Cuirass on my local computer but I have encountered a few
problems while doing it. It turned out that I had an old version of
guile-sqlite3 installed by guix. I have spent some time discovering this
issue. Eventually, I've found that all I had to do is to update guix
packages list invoking "guix pull" and then update the packages.

Unfortunately, I have no experience of IRC usage and I'm not sure how to do
in a proper way. Of course, I would like to communicate with the community,
but I'm not sure which discussions are relevant in the IRC. For instance,
could I ask questions on building issues similar to ones I've encountered?

I have taken a look at Danny's Cuirass frontend application. Now I try to
run it locally. I have already figured out that I need to change URLPREFIX
and name of the repository and the branch in the code. But I still can't
get it working. According to the browser console, all the queries to
localhost sent by js receive following error:

"No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'null' is therefore not allowed access."

But similar queries work well if I enter them manually via the browser or
curl. Could you give me any hints on that?

Best regards,
Tatiana

2018-05-09 20:21 GMT+03:00 Ricardo Wurmus :

> Hi Tatiana,
>
> we haven’t heard from you since about a week, nor have I seen you on
> IRC.  (Granted, I was offline for some time, so I probably just missed
> your introduction.)
>
> The official so-called “community bonding period” of GSoC is soon coming
> to an end, and it would be advisable to use the remaining time before
> coding begins for some community bonding :)
>
> I’d like to repeat that frequent communication is the key to a
> successful GSoC project.  If you have any questions about the project,
> the code, or how to proceed, please don’t hesitate to let us know.
>
> Thanks!
>
> --
> Ricardo
>
>

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Gábor Boskovits]

2018-05-13 20:45 GMT+02:00 Tatiana Sholokhova :

> Hi all,
>
> Thank you for your help and the provided resources which are very useful
> for me at the first stage of the project.
>
> I have built Cuirass on my local computer but I have encountered a few
> problems while doing it. It turned out that I had an old version of
> guile-sqlite3 installed by guix. I have spent some time discovering this
> issue. Eventually, I've found that all I had to do is to update guix
> packages list invoking "guix pull" and then update the packages.
>
> Unfortunately, I have no experience of IRC usage and I'm not sure how to
> do in a proper way. Of course, I would like to communicate with the
> community, but I'm not sure which discussions are relevant in the IRC. For
> instance, could I ask questions on building issues similar to ones I've
> encountered?
>
> I have taken a look at Danny's Cuirass frontend application. Now I try to
> run it locally. I have already figured out that I need to change URLPREFIX
> and name of the repository and the branch in the code. But I still can't
> get it working. According to the browser console, all the queries to
> localhost sent by js receive following error:
>
> "No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'null' is therefore not allowed access."
>
> But similar queries work well if I enter them manually via the browser or
> curl. Could you give me any hints on that?
>
>
Hello Tatiana,

by any chance do you run this code through a file:///... url? Origin null
usually means that. If so, it would be better to test in a locally
installed webserver.


> Best regards,
> Tatiana
>
> 2018-05-09 20:21 GMT+03:00 Ricardo Wurmus :
>
>> Hi Tatiana,
>>
>> we haven’t heard from you since about a week, nor have I seen you on
>> IRC.  (Granted, I was offline for some time, so I probably just missed
>> your introduction.)
>>
>> The official so-called “community bonding period” of GSoC is soon coming
>> to an end, and it would be advisable to use the remaining time before
>> coding begins for some community bonding :)
>>
>> I’d like to repeat that frequent communication is the key to a
>> successful GSoC project.  If you have any questions about the project,
>> the code, or how to proceed, please don’t hesitate to let us know.
>>
>> Thanks!
>>
>> --
>> Ricardo
>>
>>
>

Re: Code of Conduct and Diversity Statement

[Chris Marusich]

swedebugia  writes:

> This community does not really have any maintainers or formal
> leadership to my knowledge.
> How to handle reporting in our case could be handled by here by vote
> appointing a person to handle such issues (for example as a mediator
> like in https://www.noisebridge.net/wiki/Conflict_Resolution)

GNU Guix does have some maintainers.  Currently, they are Ludovic
Courtès and Ricardo Wurmus.  This is mentioned here:

https://www.gnu.org/software/guix/about/

-- 
Chris


signature.asc
Description: PGP signature

Re: Nairobi Guix talk

[Ludovic Courtès]

Pjotr Prins  skribis:

> First white hat GNU Guix talk in Africa (I think):
>
>   
> https://www.eventbrite.com/e/pjotr-prins-in-nairobi-on-functional-programming-hpcs-in-research-gnu-guix-tickets-45970402712

Excellent, thanks for the heads-up!

Ludo’.

Re: Code of Conduct and Diversity Statement

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> Tonton  writes:
>
>> Should we make the CoC more prominent or somehow inform about it
>> better? For example by putting it or a link to it in the topic of the
>> IRC channel, as it's own page on the website, if possible as part of
>> the welcome message to the mailing lists, others?
>
> I think those are good ideas.  I'd be curious to hear what Ludo and
> Ricardo think.
>
> We mention the Code of Conduct in the manual (see: "(guix)
> Contributing").  However, you're right that it seems we don't
> prominently mention it on the website.

Sure, perhaps we should mention it at the top of
 and/or link to
?

> While we wait for Ludo and Ricardo to reply, perhaps you could submit a
> patch that implements the changes you're suggesting?

That’d be great!

>> A second question is, the contributor covenant has evolved, should we upgrade
>> ours from 1.3.0 to the current
>> [1.4.0](https://www.contributor-covenant.org/version/1/4/code-of-conduct)?
>
> To help people understand what has changed going from 1.3.0 to 1.4, here
> is a handy command you can use to get a visual diff of the versions:
>
>   wdiff -n -w $'\033[30;41m' -x $'\033[0m' -y $'\033[30;42m' -z $'\033[0m' \
>   <(curl 
> https://www.contributor-covenant.org/version/1/3/0/code-of-conduct.txt) \
>   <(curl 
> https://www.contributor-covenant.org/version/1/4/code-of-conduct.txt) \
>   | less -R

As I see it, the new version is more clearly structured, clarifies the
wording in some places, and introduces a distinction between “project
team” and “project maintainers”.  Perhaps we’d need to clarify what the
“project team” is in our case (?).

Apart from this, I think 1.4 follows the spirit of 1.3.0 and its
clarifications are welcome, so I’d be in favor of “upgrading”.

What do people think?

Thanks for sharing your thoughts, Tonton!

Ludo’.

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Danny Milosavljevic]

Hi Tatiana,

> I have taken a look at Danny's Cuirass frontend application. Now I try to
> run it locally. I have already figured out that I need to change URLPREFIX
> and name of the repository and the branch in the code. But I still can't
> get it working. According to the browser console, all the queries to
> localhost sent by js receive following error:
> 
> "No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'null' is therefore not allowed access."
> 
> But similar queries work well if I enter them manually via the browser or
> curl. Could you give me any hints on that?

You're trying to run it as a file from your local computer, right?

Then it's security settings in your web browser preventing cross-site scripting
attacks.

If you use icecat, please install this extension:

  https://addons.mozilla.org/de/firefox/addon/cors-everywhere/

There's an square icon at the top right of the icecat window then (it says 
"cors").

If you click on it it will toggle between green and red.

When it's green it means that it will let all requests pass.  WHEN IT'S GREEN, 
DON'T USE ONLINE BANKING or similar in the same session.

But the index.html frontend application will work just fine then :)

When it's red it means that cross-site scripting attack protection is online.  
If in doubt, leave it red.  It should be red most of the time.

I myself develop like that:

For testing,

* Switch CorsE to green
* Refresh Cuirass frontend index.html page
* Try some stuff
* Close Cuirass frontend index.html page
* Switch CorsE to red

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Tonton]

Hi!

As far as IRC is concerned you're welcome to take any questions or
conversations that you have there. When people are online it tends to be
faster, and some problems - like live troubleshooting - is better suited to
IRC.

Personally I ask on IRC when I have a question. If it isn't answered or if my
problem is more complex, or maybe it requires a longer explanation, I'll send
it to the mailing list.

All you really need to try is an IRC client (there are also ones you can run
in your browser). And join server chat.freenode.net (port 6697 (or 6667
without ssl)) and channel #guix

Drop by and say hello if you like.

I'm not familiar with cuirass, so I can't help there, sorry. But good luck!

On Sun, 13 May 2018 21:45:04 +0300
Tatiana Sholokhova  wrote:

> Hi all,
> 
> Thank you for your help and the provided resources which are very useful
> for me at the first stage of the project.
> 
> I have built Cuirass on my local computer but I have encountered a few
> problems while doing it. It turned out that I had an old version of
> guile-sqlite3 installed by guix. I have spent some time discovering this
> issue. Eventually, I've found that all I had to do is to update guix
> packages list invoking "guix pull" and then update the packages.
> 
> Unfortunately, I have no experience of IRC usage and I'm not sure how to do
> in a proper way. Of course, I would like to communicate with the community,
> but I'm not sure which discussions are relevant in the IRC. For instance,
> could I ask questions on building issues similar to ones I've encountered?
> 
> I have taken a look at Danny's Cuirass frontend application. Now I try to
> run it locally. I have already figured out that I need to change URLPREFIX
> and name of the repository and the branch in the code. But I still can't
> get it working. According to the browser console, all the queries to
> localhost sent by js receive following error:
> 
> "No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'null' is therefore not allowed access."
> 
> But similar queries work well if I enter them manually via the browser or
> curl. Could you give me any hints on that?
> 
> Best regards,
> Tatiana
> 
> 2018-05-09 20:21 GMT+03:00 Ricardo Wurmus :
> 
> > Hi Tatiana,
> >
> > we haven’t heard from you since about a week, nor have I seen you on
> > IRC.  (Granted, I was offline for some time, so I probably just missed
> > your introduction.)
> >
> > The official so-called “community bonding period” of GSoC is soon coming
> > to an end, and it would be advisable to use the remaining time before
> > coding begins for some community bonding :)
> >
> > I’d like to repeat that frequent communication is the key to a
> > successful GSoC project.  If you have any questions about the project,
> > the code, or how to proceed, please don’t hesitate to let us know.
> >
> > Thanks!
> >
> > --
> > Ricardo
> >
> >  



-- 
I use gpg to sign my emails. All the symbols you may see at the bottom
of this mail is my cryptographic signature. It can be ignored, or used
to check that it really is me sending this email. Learn more by asking
me or see: https://u.fsf.org/zb or https://ssd.eff.org/


pgp0gGg_0ZhAj.pgp
Description: OpenPGP digital signature

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Ricardo Wurmus]

Hi Tatiana,

> Unfortunately, I have no experience of IRC usage and I'm not sure how to do
> in a proper way. Of course, I would like to communicate with the community,
> but I'm not sure which discussions are relevant in the IRC. For instance,
> could I ask questions on building issues similar to ones I've encountered?

Yes, anything relating to the project that is easier discussed live is
appropriate for the IRC channel.

If you don’t have an IRC client you can use

https://webchat.freenode.net/

Input any nickname and #guix as the channel.

-- 
Ricardo

Re: Code of Conduct and Diversity Statement

[Kei Kebreau]

l...@gnu.org (Ludovic Courtès) writes:

>
> As I see it, the new version is more clearly structured, clarifies the
> wording in some places, and introduces a distinction between “project
> team” and “project maintainers”.  Perhaps we’d need to clarify what the
> “project team” is in our case (?).
>
> Apart from this, I think 1.4 follows the spirit of 1.3.0 and its
> clarifications are welcome, so I’d be in favor of “upgrading”.
>
> What do people think?
>
> Thanks for sharing your thoughts, Tonton!
>
> Ludo’.

I'm also in favor of the move to version 1.4.


signature.asc
Description: PGP signature

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Chris Marusich]

Tatiana Sholokhova  writes:

> Unfortunately, I have no experience of IRC usage and I'm not sure how to do
> in a proper way. Of course, I would like to communicate with the community,
> but I'm not sure which discussions are relevant in the IRC. For instance,
> could I ask questions on building issues similar to ones I've encountered?

If you need a specific recommendation, I'd suggest you try HexChat for
IRC.  It's available in Guix via "guix package -i hexchat".  There are
other clients, but I've found this one works quite nicely for my simple
needs.

Another popular option I know of is Pidgin, which is also packaged in
Guix.  I haven't used the Guix-installed Pidgin before, though, so I
don't know how well it works at this time.

-- 
Chris


signature.asc
Description: PGP signature