[GSoC] Development of Cuirass.

[GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hi,

Here is my proposal for the Google Summer of Code 2017.

1 Introduction
══════════════

  [Cuirass] is a build automation server using GNU Guix package manager.
  This project has started last year as a Google Summer of Code (GSoC)
  with the goal of replacing [Hydra] which is the continous build server
  used by Nix and Guix to provide package substitutes.  Cuirass intends
  to be a multi-purpose build automation server.  It aims at allowing
  users to have their own build farm for packages they maintain outside
  of Guix tree, and at providing a tool for applying the principle of
  continuous integration[1] in software development.  To achieve this
  goal a lot of things remain to be done.


  [Cuirass] https://notabug.org/mthl/cuirass

  [Hydra] https://nixos.org/hydra/


2 Proposal
══════════

  The project is the continuation of last year work, and is separated in
  two parts.  The first part is to improve the testing infrastructure.
  The second one is about providing a more complete HTTP API.


2.1 The testing infrastructure
──────────────────────────────

  Currently Cuirass is providing a small test suite consisting only of
  unit tests.  The integration tests are done manually with basic
  examples consisting in building small packages such as GNU Hello.
  This is not good, because actual packages take a consequent time to
  compile, and testing only basic examples leaves the interesting
  complex case out of the scope of testing.  The worst is that the
  result depend on the phase of the moon since every commit in Guix can
  potentially break the build.

  The idea is to take inspiration from the Guix test suite by providing
  tiny mocked packages that will help having lightweight build
  specifications.  Those tests require launching another instance of the
  `guix-daemon' with a local temporary store.


2.2 HTTP API
────────────

  Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a
  web server which is running in a separate thread of the `cuirass'
  process.  However the resources it provides are pretty limited since
  you can only query the lists of specifications currently watched.
  This is done with the `/specifications' or `/jobsets' resource names.
  "Jobsets" is the terminology used by Hydra and is used here for
  compatibility with its HTTP API.

  The principal objective of this part is to provide a more complete API
  which allows users to query the build results and to add their
  specifications to the current set.  The design of this API will apply
  the principles of the Representational State Transfert (REST)
  architectural pattern[2].  Sensitive requests should be done with an
  authentification mechanism which is not determined yet.  I currently
  have no experience with any and lack the knowledge to properly choose
  one.


  [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2]
  https://notabug.org/mthl/cuirass/commit/12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2


3 Roadmap
═════════

  This roadmap lacks details about the concrete tasks and its associated
  timeline.  However I prefer having some feedback about this proposal
  first, before providing a complete roadmap.

  • From May 30 to June 26, I will work on the testing infrastructure,.
  • From June 27 to August 29, I will work on the HTTP API.


4 Feedback
══════════

  Some people have expressed their interest in having a Web /frontend/
  for Cuirass.  To avoid possible confusions I have no plan in working
  on it this summer.  While this would be a very valuable effort, I
  don't feel up to the task.

  Regarding the Authentification mechanism, any enlighten advice or
  resource would be welcome.  If anybody think of other important tasks
  that need to be addressed, please share.



Footnotes
─────────

[1] [https://martinfowler.com/articles/continuousIntegration.html]

[2] [https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm]

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[pelzflorian (Florian Pelz)]

Hello,

On 03/12/2017 03:49 PM, Mathieu Lirzin wrote:
> Sensitive requests should be done with an
>   authentification mechanism which is not determined yet.  I currently
>   have no experience with any and lack the knowledge to properly choose
>   one.

I’m new to Guix and Scheme and no expert in Web programming, but in
order to prevent CSRF and in order not to rely on JavaScript, the server
should run with HTTPS (of course) and
· use a secret session token and
· send a customized Web page to the client adapted so that each link and
form to the server includes the session token as a GET or POST parameter.

An alternative is Basic Access Authentication with HTTPS or Cookies with
HTTPS but they are vulnerable to CSRF.

See stackoverflow, for example

https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication

Maybe others don’t take such a strong stance against JavaScript and
prefer another method, but I believe JavaScript does not belong in the Web.

Regards,
Florian

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hello Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On 03/12/2017 03:49 PM, Mathieu Lirzin wrote:
>> Sensitive requests should be done with an
>>   authentification mechanism which is not determined yet.  I currently
>>   have no experience with any and lack the knowledge to properly choose
>>   one.
>
> I’m new to Guix and Scheme and no expert in Web programming, but in
> order to prevent CSRF and in order not to rely on JavaScript, the server
> should run with HTTPS (of course) and
> · use a secret session token and
> · send a customized Web page to the client adapted so that each link and
> form to the server includes the session token as a GET or POST parameter.
>
> An alternative is Basic Access Authentication with HTTPS or Cookies with
> HTTPS but they are vulnerable to CSRF.
>
> See stackoverflow, for example
>
> https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication

Thanks for your input.

Have you any experience/advice regarding OAuth or Json Web Token (JWT) ?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[pelzflorian (Florian Pelz)]

On 03/12/2017 07:41 PM, Mathieu Lirzin wrote:
> Hello Florian,
> 
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> 
>> On 03/12/2017 03:49 PM, Mathieu Lirzin wrote:
>>> Sensitive requests should be done with an
>>>   authentification mechanism which is not determined yet.  I currently
>>>   have no experience with any and lack the knowledge to properly choose
>>>   one.
>>
>> I’m new to Guix and Scheme and no expert in Web programming, but in
>> order to prevent CSRF and in order not to rely on JavaScript, the server
>> should run with HTTPS (of course) and
>> · use a secret session token and
>> · send a customized Web page to the client adapted so that each link and
>> form to the server includes the session token as a GET or POST parameter.
>>
>> An alternative is Basic Access Authentication with HTTPS or Cookies with
>> HTTPS but they are vulnerable to CSRF.
>>
>> See stackoverflow, for example
>>
>> https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication
> 
> Thanks for your input.
> 
> Have you any experience/advice regarding OAuth or Json Web Token (JWT) ?
> 

Sorry, I have no experience with these. I think I’ve basically
understood what OAuth is for after reading the OSM wiki, [1] but I’m not
sure what you want to use it for.

I assume the following scenario:


The user wants to log in.

· The Cuirass Web server would receive the log-in credentials as POST
parameters from an HTML form.

· Now it needs to check whether the password is correct, e.g. by looking
up the salt stored for the supplied username, computing the bcrypt hash
of the supplied password and stored salt and comparing it to the stored
bcrypt hash for the user name.    ← This requires Cuirass to store a
table containing user names, salts and bcrypt hashes. Do you intend to
use some OAuth / OpenID / whatever thing to outsource the log-in
management to an “identity provider”? I presume you don’t.

· You generate a secret session token shared between server and client
which you
  — embed in each link and in each form you send to the client as part
of the session and
  — can verify the session token on the server.    ← I did not know
about JWT, but from a first glance it seems very appropriate for this
use. Instead of storing on the server which sessions are still active,
the token stores all information about the log-in and its content is
encrypted with the server’s secret key. This seems like a great idea,
also there maybe is (or should be) a library to manage JWT. I learned
something today. :)


By the way, your plans for Cuirass sound great. Thank you!

Regards,
Florian

[1] https://wiki.openstreetmap.org/wiki/OAuth

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On 03/12/2017 07:41 PM, Mathieu Lirzin wrote:
>> Hello Florian,
>> 
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
>> 
>>> On 03/12/2017 03:49 PM, Mathieu Lirzin wrote:
>>>> Sensitive requests should be done with an
>>>>   authentification mechanism which is not determined yet.  I currently
>>>>   have no experience with any and lack the knowledge to properly choose
>>>>   one.
>>>
>>> I’m new to Guix and Scheme and no expert in Web programming, but in
>>> order to prevent CSRF and in order not to rely on JavaScript, the server
>>> should run with HTTPS (of course) and
>>> · use a secret session token and
>>> · send a customized Web page to the client adapted so that each link and
>>> form to the server includes the session token as a GET or POST parameter.
>>>
>>> An alternative is Basic Access Authentication with HTTPS or Cookies with
>>> HTTPS but they are vulnerable to CSRF.
>>>
>>> See stackoverflow, for example
>>>
>>> https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication
>> 
>> Thanks for your input.
>> 
>> Have you any experience/advice regarding OAuth or Json Web Token (JWT) ?
>> 
>
> Sorry, I have no experience with these. I think I’ve basically
> understood what OAuth is for after reading the OSM wiki, [1] but I’m not
> sure what you want to use it for.
>
> I assume the following scenario:
>
>
> The user wants to log in.
>
> · The Cuirass Web server would receive the log-in credentials as POST
> parameters from an HTML form.
>
> · Now it needs to check whether the password is correct, e.g. by looking
> up the salt stored for the supplied username, computing the bcrypt hash
> of the supplied password and stored salt and comparing it to the stored
> bcrypt hash for the user name.    ← This requires Cuirass to store a
> table containing user names, salts and bcrypt hashes. Do you intend to
> use some OAuth / OpenID / whatever thing to outsource the log-in
> management to an “identity provider”? I presume you don’t.
>
> · You generate a secret session token shared between server and client
> which you
>   — embed in each link and in each form you send to the client as part
> of the session and
>   — can verify the session token on the server.    ← I did not know
> about JWT, but from a first glance it seems very appropriate for this
> use. Instead of storing on the server which sessions are still active,
> the token stores all information about the log-in and its content is
> encrypted with the server’s secret key. This seems like a great idea,
> also there maybe is (or should be) a library to manage JWT. I learned
> something today. :)

I need to do my homework before being able to go further in this
discussion.  Thanks for you analysis.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[Ludovic Courtès]

Hello Mathieu!

Mathieu Lirzin <mthl@gnu.org> skribis:

>   The project is the continuation of last year work, and is separated in
>   two parts.  The first part is to improve the testing infrastructure.
>   The second one is about providing a more complete HTTP API.

Sounds cool!

> 2.1 The testing infrastructure
> ──────────────────────────────
>
>   Currently Cuirass is providing a small test suite consisting only of
>   unit tests.  The integration tests are done manually with basic
>   examples consisting in building small packages such as GNU Hello.
>   This is not good, because actual packages take a consequent time to
>   compile, and testing only basic examples leaves the interesting
>   complex case out of the scope of testing.  The worst is that the
>   result depend on the phase of the moon since every commit in Guix can
>   potentially break the build.
>
>   The idea is to take inspiration from the Guix test suite by providing
>   tiny mocked packages that will help having lightweight build
>   specifications.  Those tests require launching another instance of the
>   `guix-daemon' with a local temporary store.

Sounds like a good idea.

It would be nice to refine what it is we’re trying to test and that’s
not addressed by unit tests.  At one end of the spectrum, I imagine we
could be spawning a couple of GuixSD VMs connected together, one serving
a Git repo, and the other one running Cuirass pulling from that repo (a
system test).

At the middle of the spectrum is something like you describe, I think:
run Cuirass directly upon “make check”, though there are complications:
what repo do we pull from, do we really want to build packages and if
not how to we mock builds, etc.

There are several components we’d like to test more closely IMO: SCM
polling, evaluation, and job scheduling.  Perhaps some of that can also
be achieved through unit tests?

> 2.2 HTTP API
> ────────────
>
>   Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a
>   web server which is running in a separate thread of the `cuirass'
>   process.  However the resources it provides are pretty limited since
>   you can only query the lists of specifications currently watched.
>   This is done with the `/specifications' or `/jobsets' resource names.
>   "Jobsets" is the terminology used by Hydra and is used here for
>   compatibility with its HTTP API.

For a start, I think we should implement all or a subset of the Hydra
API, as-is (it’s currently used by Emacs-Guix):

  https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Controller/API.pm

A large part of it is about monitoring the status of Hydra: queued
builds, recently-completed builds, jobs, etc.  That is the most pressing
need, I think.

>   The principal objective of this part is to provide a more complete API
>   which allows users to query the build results and to add their
>   specifications to the current set.  The design of this API will apply
>   the principles of the Representational State Transfert (REST)
>   architectural pattern[2].  Sensitive requests should be done with an
>   authentification mechanism which is not determined yet.  I currently
>   have no experience with any and lack the knowledge to properly choose
>   one.

pelzflorian already gave good ideas, so that’s good.  :-)

>   This roadmap lacks details about the concrete tasks and its associated
>   timeline.  However I prefer having some feedback about this proposal
>   first, before providing a complete roadmap.
>
>   • From May 30 to June 26, I will work on the testing infrastructure,.
>   • From June 27 to August 29, I will work on the HTTP API.

You may find that you’ll want to interleave tasks.  I don’t know about
you, but sometimes I get bored if I keep working on the same task or
domain for too long, so switching to something else for a while can be a
relief.  :-)

There are a couple of isolated tasks that come to mind, which do not
really fit in the proposal but are worth looking into as time permits:

  • improved error reporting upon evaluation failures and so on;

  • improved error recovery;

  • use of Guile-Git instead of Git.

> 4 Feedback
> ══════════
>
>   Some people have expressed their interest in having a Web /frontend/
>   for Cuirass.  To avoid possible confusions I have no plan in working
>   on it this summer.  While this would be a very valuable effort, I
>   don't feel up to the task.

Understood.  That said, once the JSON API is in place, Web-savvy people
could certainly come with a JSish frontend.  It might be that
<https://github.com/hercules-ci/hercules> would work.

Thanks for posting this proposal!

Ludo’.

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hi,

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

>> 2.1 The testing infrastructure
>> ──────────────────────────────
>>
>>   Currently Cuirass is providing a small test suite consisting only of
>>   unit tests.  The integration tests are done manually with basic
>>   examples consisting in building small packages such as GNU Hello.
>>   This is not good, because actual packages take a consequent time to
>>   compile, and testing only basic examples leaves the interesting
>>   complex case out of the scope of testing.  The worst is that the
>>   result depend on the phase of the moon since every commit in Guix can
>>   potentially break the build.
>>
>>   The idea is to take inspiration from the Guix test suite by providing
>>   tiny mocked packages that will help having lightweight build
>>   specifications.  Those tests require launching another instance of the
>>   `guix-daemon' with a local temporary store.
>
> Sounds like a good idea.
>
> It would be nice to refine what it is we’re trying to test and that’s
> not addressed by unit tests.  At one end of the spectrum, I imagine we
> could be spawning a couple of GuixSD VMs connected together, one serving
> a Git repo, and the other one running Cuirass pulling from that repo (a
> system test).
>
> At the middle of the spectrum is something like you describe, I think:
> run Cuirass directly upon “make check”, though there are complications:
> what repo do we pull from, do we really want to build packages and if
> not how to we mock builds, etc.

The idea I had was to create fake vcs repositories programmatically.  I
imagine that it is possible to associate some dummy build script that we
can deterministically make fail.

> There are several components we’d like to test more closely IMO: SCM
> polling, evaluation, and job scheduling.  Perhaps some of that can also
> be achieved through unit tests?

Yeah, that would be better.

>> 2.2 HTTP API
>> ────────────
>>
>>   Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a
>>   web server which is running in a separate thread of the `cuirass'
>>   process.  However the resources it provides are pretty limited since
>>   you can only query the lists of specifications currently watched.
>>   This is done with the `/specifications' or `/jobsets' resource names.
>>   "Jobsets" is the terminology used by Hydra and is used here for
>>   compatibility with its HTTP API.
>
> For a start, I think we should implement all or a subset of the Hydra
> API, as-is (it’s currently used by Emacs-Guix):
>
>   https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Controller/API.pm
>
> A large part of it is about monitoring the status of Hydra: queued
> builds, recently-completed builds, jobs, etc.  That is the most pressing
> need, I think.

OK.

>>   This roadmap lacks details about the concrete tasks and its associated
>>   timeline.  However I prefer having some feedback about this proposal
>>   first, before providing a complete roadmap.
>>
>>   • From May 30 to June 26, I will work on the testing infrastructure,.
>>   • From June 27 to August 29, I will work on the HTTP API.
>
> You may find that you’ll want to interleave tasks.  I don’t know about
> you, but sometimes I get bored if I keep working on the same task or
> domain for too long, so switching to something else for a while can be a
> relief.  :-)

I don't know, I have been rarely confronted to that issue personnaly
(more the opposite: too much context switching).  But I will
preventively adapt my roadmap.

> There are a couple of isolated tasks that come to mind, which do not
> really fit in the proposal but are worth looking into as time permits:
>
>   • improved error reporting upon evaluation failures and so on;
>
>   • improved error recovery;

I totally forgot to precise that the error handling issue is exactly the
reason I think we need a better test infrastructure for Cuirass.  Being
able to reproduce various errors or failues allows a better confidence
in the error being properly handled.  I find it hard to just imagine
and write the appropriate handler.

>   • use of Guile-Git instead of Git.

I Will add this to the plan.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[Andy Wingo]

On Sun 12 Mar 2017 15:49, Mathieu Lirzin <mthl@gnu.org> writes:

> Here is my proposal for the Google Summer of Code 2017.

Looks great to me.  FWIW I think you may want to use Fibers in Cuirass.
Sometimes a web API request might need to "fork" off a number of tasks,
and Fibers lets you do that pretty easily, and provides nice
communications mechanisms for inter-fiber communication like channels
and condition variables.  It also prevents one long API request from
starving other API users.  Also its abstractions are thread-safe, and it
enables parallel speedups by using all available cores.

Right now Fibers doesn't have explicit support for subprocess events
like child-died, etc, though it can do concurrent access to multiple
pipes at once.  So there's some work to do here.

A reference:

  https://github.com/wingo/fibers/wiki/Manual

Specifically see the "web server" notes in the Examples section.  Fibers
is in Guix as "guile-fibers".

Happy hacking,

Andy

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hello,

Andy Wingo <wingo@igalia.com> writes:

> On Sun 12 Mar 2017 15:49, Mathieu Lirzin <mthl@gnu.org> writes:
>
>> Here is my proposal for the Google Summer of Code 2017.
>
> Looks great to me.  FWIW I think you may want to use Fibers in Cuirass.
> Sometimes a web API request might need to "fork" off a number of tasks,
> and Fibers lets you do that pretty easily, and provides nice
> communications mechanisms for inter-fiber communication like channels
> and condition variables.  It also prevents one long API request from
> starving other API users.  Also its abstractions are thread-safe, and it
> enables parallel speedups by using all available cores.
>
> Right now Fibers doesn't have explicit support for subprocess events
> like child-died, etc, though it can do concurrent access to multiple
> pipes at once.  So there's some work to do here.
>
> A reference:
>
>   https://github.com/wingo/fibers/wiki/Manual
>
> Specifically see the "web server" notes in the Examples section.  Fibers
> is in Guix as "guile-fibers".

Looks interesting.

The web server that uses the standard interface seems not that
difficult to integrate.

I will add that to the road-map.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[Efraim Flashner]

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

On Sun, Mar 12, 2017 at 03:49:47PM +0100, Mathieu Lirzin wrote:
> Hi,
> 
> Here is my proposal for the Google Summer of Code 2017.
...
> 
> 4 Feedback
> ══════════
> 
>   Some people have expressed their interest in having a Web /frontend/
>   for Cuirass.  To avoid possible confusions I have no plan in working
>   on it this summer.  While this would be a very valuable effort, I
>   don't feel up to the task.
> 

I don't know all that much about it, but when joeyh implemented the
git-annex assitant with a web frontend he used bootstrap and called it
"easy". I don't know if it is easy or not, but I wouldn't think of him
of as web guy.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hi,

Mathieu Lirzin <mthl@gnu.org> writes:

> Here is my proposal for the Google Summer of Code 2017.

I have updated it, according to the various feedback I had.  Here is the
link:

  http://mathieu.lirzin.emi.u-bordeaux.fr/gsoc/guix.html

I must say that given the current agitation in Guix community for gender
related issues, I am sorry to say that I withdraw my proposal.

A majority of people in this community seems to adhere to political
ideas related to feminism and LGBT causes and are very vocal about it.
While I respect people having such conviction, the fact that those
ideas/values are repeatedly presented as if every one should adhere to
them is not welcoming for those who disagree.

As a consequence I would rather spend my time working on Free Software
projects that I consider more tolerant.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Development of Cuirass.

[Ludovic Courtès]

Hi Mathieu,

Mathieu Lirzin <mthl@gnu.org> skribis:

> A majority of people in this community seems to adhere to political
> ideas related to feminism and LGBT causes and are very vocal about it.
> While I respect people having such conviction, the fact that those
> ideas/values are repeatedly presented as if every one should adhere to
> them is not welcoming for those who disagree.

You’ve said it before and that’s a misunderstanding.  Ricardo and I, as
maintainers, are trying to acknowledge an issue that is very real in
free software and tech groups, and we’re doing the little we can do to
avoid these problems in our group.  There is nothing you or I lose.

> As a consequence I would rather spend my time working on Free Software
> projects that I consider more tolerant.

Very harsh to say the least.  :-(

Good luck with your future endeavors.

Ludo’.

Re: [GSoC] Development of Cuirass.

[Jan Nieuwenhuizen]

Mathieu Lirzin writes:

> I must say that given the current agitation in Guix community for gender
> related issues, I am sorry to say that I withdraw my proposal.

Sorry to hear that.

> A majority of people in this community seems to adhere to political
> ideas related to feminism and LGBT causes and are very vocal about it.
> While I respect people having such conviction, the fact that those
> ideas/values are repeatedly presented as if every one should adhere to
> them is not welcoming for those who disagree.
>
> As a consequence I would rather spend my time working on Free Software
> projects that I consider more tolerant.

Wow, I'm shocked to read this!  Let me check.  Are you saying that
condoning disrespectful/non-considerate behaviour is actually
"tolerance" and preferrable when building a community?

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: [GSoC] Development of Cuirass.

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 435 bytes --]

Mathieu,

On 21/03/17 15:31, Mathieu Lirzin wrote:
> I must say that given the current agitation in Guix community for gender
> related issues, I am sorry to say that I withdraw my proposal.

I'm also very sorry to see you go.

> As a consequence I would rather spend my time working on Free Software
> projects that I consider more tolerant.

I hope you find whatever it is you're looking for.

Kind regards,

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]

Re: [GSoC] Development of Cuirass.

[Leo Famulari]

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

On Tue, Mar 21, 2017 at 03:31:01PM +0100, Mathieu Lirzin wrote:
> Hi,
> 
> Mathieu Lirzin <mthl@gnu.org> writes:
> 
> > Here is my proposal for the Google Summer of Code 2017.
> 
> I have updated it, according to the various feedback I had.  Here is the
> link:
> 
>   http://mathieu.lirzin.emi.u-bordeaux.fr/gsoc/guix.html
> 
> I must say that given the current agitation in Guix community for gender
> related issues, I am sorry to say that I withdraw my proposal.
> 
> A majority of people in this community seems to adhere to political
> ideas related to feminism and LGBT causes and are very vocal about it.
> While I respect people having such conviction, the fact that those
> ideas/values are repeatedly presented as if every one should adhere to
> them is not welcoming for those who disagree.
> 
> As a consequence I would rather spend my time working on Free Software
> projects that I consider more tolerant.

I'm really disappointed that this is the result of that discussion.

I do think that Ludovic is right: we lose nothing by trying to address
the gender imbalance in our community.

I sincerely hope you'll reconsider leaving the Guix project. And if you
keep your decision, I wish you luck in whatever you do.

Sincerely,
Leo

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

Re: [GSoC] Development of Cuirass.

[Ricardo Wurmus]

Hi Mathieu,

> A majority of people in this community seems to adhere to political
> ideas related to feminism and LGBT causes and are very vocal about it.
> While I respect people having such conviction, the fact that those
> ideas/values are repeatedly presented as if every one should adhere to
> them is not welcoming for those who disagree.
>
> As a consequence I would rather spend my time working on Free Software
> projects that I consider more tolerant.

I find it sad that we have different interpretations of what it means
for projects to be tolerant, and I’m disappointed to see you leave like
that.  Like Ludo said: there’s nothing for any of us to lose in trying
what we can to make this project more welcoming than what is sadly the
norm in many software project.

A practical question: Will you continue to work on and maintain Cuirass
at your notabug repository or should someone here take over maintenance
of this project?  I was about to work on some patches and would like to
know if you decided to abandon Cuirass.

Thank you for you past contributions.

--
Ricardo

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