Re: Meta Guix: why guix is awesome!

[Pjotr Prins]

Hi Leo (Prikler),

On Thu, Apr 29, 2021 at 01:52:12AM +0200, Leo Prikler wrote:
> I don't know enough about marketing to give you a good answer on that,
> but when it comes to what we're competing against, it seems to be a
> rather uphill battle outside of the small bubble, that we've carved
> out.  According to distrowatch we're still far away from Nix and back
> when I was using Gentoo I thought that was some super niche distro.

As Guix is now also a Debian package I think it is doing extremely
well. I know people who are silently introducing Guix :). As a full
distro it may be niche, but it is also very successful because it
keeps growing and growing. Nix has a 10 years head start (I was there)
and does better in industry, but it does not mean it wil be ahead in
another 10 years.

Look where Linux came from.

> Guix may perhaps not be the smallest package manager (to be honest, I
> have no way of telling as it's the only one I'm involved in), but I can
> definitely say, that it does things well, so your point about violating
> Unix philosophy is invalidated :P

Guix abides by the Unix philosophy in many ways. All the tools (or
their invocations) do the minimum. It is actually an interesting
mixture of composition and isolation. Guix has the advantage of
learning from other attempts. But think about the Guix choice of
shepherd over systemd: systemd is not a tool in the spirit of Unix (in
my opinion) because it tries to think for you and can be unpredictable
:). Guix' focus is on being predictable and hackable - i.e., very Unix
spirited.

> Also, Guix does not yet write email for you, we still have to offload
> that to git.

Ah, yes. I would like that feature.

> Which ties back to point 2.  Guix aims to be inclusive and being
> inclusive means toning down the rudeness.

That is true. Though rudeness can also serve a purpose (Linus comes to
mind though he is trying to tone down the last years) and some people
can't help it. We walk a fine line here when we tell people to be less
rude and lose some value if we can not be honest. There is a cultural
angle for sure. The Fins, Dutch, Russians and Germans can be honest in
their language, but that appears as rude in English. Common English
can be extremely rude in Japanese. I think, in an intercultural sense,
we ought to strive for not taking everything at face value, and try
reading beyond the surface. Some people are in the autistic spectrum,
do we shut them down and have them not participate? I don't think that
is particularly inclusive either. 

Even so, if someone crosses a line with intent to hurt we should have
policies that protect the attacked. That is civil.  But I'd argue
against judging people by popular opinion. Courts of law are there to
judge badness.  Likewise, projects have policies and a code of
conduct. We should abide by those (the alternative being that people
can decide not to participate with the project). It is very hard,
perhaps impossible, to defend yourself against (perceived) popular
opinion.

Character assassination on the internet is all to common now. What we
should aim for is trying to keep discussion technical in a technical
project, even is it is in reality also a social experiment - as all of
free software is and even humanity as a whole. The good news is that
almost all our discussions and choices can be technical.

> - I don't think anyone has ever been offended by trees – it's usually
> the other way round – but there are (some reasonable and some less
> reasonable) arguments to support one's fear of spiders, both physical
> and digital.

We had a cat that got stuck in a tree once. Since that time he looked
up and we could virtually see him think: trees are evil. He never went
up again.

Trees can be perceived as evil even if they are obviously benefitial.
Being inclusive actually implies celebrating our differences. 

Pj.

Re: ISO image: to xz or not to xz?

[Leo Famulari]

On Wed, Apr 28, 2021 at 10:18:01PM +0200, Ludovic Courtès wrote:
> What do people think?

We've received several complaints about the images being compressed. I
guess we might as well offer it uncompressed, and maybe offer both ways.

Re: ISO image: to xz or not to xz?

[Christopher Baines]

Ludovic Courtès  writes:

> Hi!
>
> Here’s the installation ISO image (with built-in zlib compression):
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm
> /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
> $ xz < /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso > /tmp/t.iso.xz
> $ du -h /tmp/t.iso.xz
> 496M  /tmp/t.iso.xz
> $ du -h /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
> 647M  /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
> --8<---cut here---end--->8---
>
> The xz-compressed image is 23% smaller, which is not negligible.
> However, it’s apparently quite unusual to distribute compressed ISOs and
> some services/tools such as libosinfo require plain ISOs (uncompressed).
>
> Should we distribute the installation ISO without xz compression?

Personally I think the ISO is more useful if it's published as such,
rather than an as a xz compressed file.

I believe this will make things like getting Guix through Gnome Boxes
easier, and using Guix at various hosting providers easier.


signature.asc
Description: PGP signature

Re: ISO image: to xz or not to xz?

[Development of GNU Guix and the GNU System distribution.]

Ludovic Courtès  writes:

> Should we distribute the installation ISO without xz compression?

Yes.  I've always found that annoying with Guix, because it adds one
more step to the download and PGP verification process.  All of Debian,
Ubuntu, NixOS, etc distribute plain ISO's.

/Simon


signature.asc
Description: PGP signature

Re: ISO image: to xz or not to xz?

[Vincent Legoll]

On Wed, Apr 28, 2021 at 10:18 PM Ludovic Courtès  wrote:
> What do people think?

I'd say distribute both, so the bandwidth-starved can get the
smaller, and the CPU-starved can get the uncompressed one.

-- 
Vincent Legoll

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Pjotr Prins]

Dear Leo,

On Wed, Apr 28, 2021 at 01:55:25PM -0400, Leo Famulari wrote:
> You should have sent a message that explained the problem and tried to
> teach the solution. I've seen you do it many times before; 

That is perhaps fair comment. It is always best to be constructive and
not too personal. The latter is probably what rubs people the wrong
way, especially in public. Good advice, in other words.

Going by my experience in Guix - if we were to meet personally we
would all be impressed by each other, that includes the other Leo and
Mark. I think Guix developers are special and all have made
interesting journeys to get here. Lisp is an great filter. I wonder
how we end up with more Leos than Marks, however ;)

But let me defend Mark here (a little). I'll only do this once. I
don't think it was malicious even if it did not look nice. Truth is we
should also try to look a little beyond the surface.  The intention
matters. What I read was exasperation.

But really, partly to prevent character assassination, I think that if
anyone crosses a line the accuser should use our complaints channels.
That is what they are for. We should not accuse each other about
behaviour in a public channel. Mostly because it is very hard to
defend oneself against opinion (of a majority). 

Pj.

ISO image: to xz or not to xz?

[Ludovic Courtès]

Hi!

Here’s the installation ISO image (with built-in zlib compression):

--8<---cut here---start->8---
$ ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm
/gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
$ xz < /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso > /tmp/t.iso.xz
$ du -h /tmp/t.iso.xz
496M/tmp/t.iso.xz
$ du -h /gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
647M/gnu/store/kg63cyg94dmy9x7rpxf5ycn97sqx1ndl-image.iso
--8<---cut here---end--->8---

The xz-compressed image is 23% smaller, which is not negligible.
However, it’s apparently quite unusual to distribute compressed ISOs and
some services/tools such as libosinfo require plain ISOs (uncompressed).

Should we distribute the installation ISO without xz compression?

That could be done in respect of the string freeze (removing text, not
modifying it), though the relevant section would look odd because it’d
have a single step (info "(guix) USB Stick and DVD Installation").

Or maybe it’s safer to postpone that question until the next release.

What do people think?

Ludo’.

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> On Wed, 28 Apr 2021 19:17:51 +0100
> Christopher Baines  wrote:
>
>> So, there's already some code for timing different parts of the data
>> loading process, if you look in the job output and search for ", took
>> " you should see timings printed out.
>>
>> These timings being printed out does help, but having the information
>> in the log doesn't make it easy to figure out which part is the
>> slowest for example.
>>
>> I'd also not consider this a "one off" thing, the data loading code
>> will continue to change as Guix changes and it's performance will
>> probably change too.
>>
>> I've been wondering about visualisations, I remember systemd had a
>> feature to plot the systems boot as a image which made seeing which
>> parts are slow much easier (here's an example [1]).
>>
>> 1: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot001.gif
>
> This is interesting! In fact, one of the things that attracted me was
> the possibility to work with visualizations, as I saw that on the
> roadmap there is one task related to provide statistics over time).
> My master degree is on Information Visualization, so I would appreciate
> very much if I could help with that.
>
> In this matter, we should determine what else, other than time, would
> be interesting to see. The visualization should be clear enough about
> timing but should also provide information about what could be related
> to the delays, such as size of the queries, complexity, the return it
> gives... So, first I think we should determine what information we want
> to see, then depending on the variables, we choose a suitable way to
> present the visualization.

I think time is the main thing, since that alone will help to identify
which are the slow parts.

> About implementing, I'm kind of new to guile and I never built a
> visualization in guile, so I don't know which libraries it would take to
> build a visual work like that. Depending on what we have,
> interactions could be compromised, and instead we would have to work
> with charts (static visualizations). Can you tell me more about that?

Given the Guix Data Service outputs HTML as well as JSON, it might be
possible to build something with HTML. The package history pages sort of
visualise the data by adding some grey bars to the table [1].

1: http://data.guix.gnu.org/repository/1/branch/master/package/guix

> And one last thing, a visualization can be simple or can be very
> complex.The time for that should be carefully taken into account in
> order to not impair the main goal which is the improvements of the slow
> parts.

Indeed, simplicity is a good thing to keep in mind.

>> > About the improvements on the performance of slow parts, it is a
>> > little bit abstract for me to see now how to break it in smaller
>> > tasks. I do believe that it would require to reformulate some parts
>> > of the queries, and as their result may change a bit, tweaks could
>> > be required on the code too. My point is, how would I propose an
>> > improvement approach if I don't even know what exactly is to be
>> > improved? But I imagine that work on this second task is more
>> > demanding than the first and will take most of the time of the
>> > internship.
>>
>> As I said before, this part is dependent on deciding where the areas
>> for improvement are. Maybe have a look through one of the job logs on
>> data.guix.gnu.org and see if you can spot some slow parts?
>
> I'll look into that and get back to you.

Great.


signature.asc
Description: PGP signature

Re: Outreachy: Timeline tasks

[Luciana Lima Brito]

On Wed, 28 Apr 2021 19:17:51 +0100
Christopher Baines  wrote:

> So, there's already some code for timing different parts of the data
> loading process, if you look in the job output and search for ", took
> " you should see timings printed out.
> 
> These timings being printed out does help, but having the information
> in the log doesn't make it easy to figure out which part is the
> slowest for example.
> 
> I'd also not consider this a "one off" thing, the data loading code
> will continue to change as Guix changes and it's performance will
> probably change too.
> 
> I've been wondering about visualisations, I remember systemd had a
> feature to plot the systems boot as a image which made seeing which
> parts are slow much easier (here's an example [1]).
> 
> 1: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot001.gif

This is interesting! In fact, one of the things that attracted me was
the possibility to work with visualizations, as I saw that on the
roadmap there is one task related to provide statistics over time). 
My master degree is on Information Visualization, so I would appreciate
very much if I could help with that.

In this matter, we should determine what else, other than time, would
be interesting to see. The visualization should be clear enough about
timing but should also provide information about what could be related
to the delays, such as size of the queries, complexity, the return it
gives... So, first I think we should determine what information we want
to see, then depending on the variables, we choose a suitable way to
present the visualization.

About implementing, I'm kind of new to guile and I never built a
visualization in guile, so I don't know which libraries it would take to
build a visual work like that. Depending on what we have,
interactions could be compromised, and instead we would have to work
with charts (static visualizations). Can you tell me more about that?

And one last thing, a visualization can be simple or can be very
complex.The time for that should be carefully taken into account in
order to not impair the main goal which is the improvements of the slow
parts.

> 
> > About the improvements on the performance of slow parts, it is a
> > little bit abstract for me to see now how to break it in smaller
> > tasks. I do believe that it would require to reformulate some parts
> > of the queries, and as their result may change a bit, tweaks could
> > be required on the code too. My point is, how would I propose an
> > improvement approach if I don't even know what exactly is to be
> > improved? But I imagine that work on this second task is more
> > demanding than the first and will take most of the time of the
> > internship.  
> 
> As I said before, this part is dependent on deciding where the areas
> for improvement are. Maybe have a look through one of the job logs on
> data.guix.gnu.org and see if you can spot some slow parts?

I'll look into that and get back to you.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> I was thinking about the timeline of tasks.
>
> The main tasks are:
>
> 1. Add instrumentation to identify the slow parts of processing
>   new revisions
>
> 2. Improve the performance of these slow parts
>
> I'm writing some ideas I have to divide the tasks in small steps, see
> what you think about it.
>
> About the first task I understand that the whole thing starts with
> identifying how the data for new revisions arrives on Guix Data
> Service: the relevant queries and their processing on the code. Based
> on it I would propose start with mapping these queries and their uses,
> so I could run them locally and get their statistics.
>
> Once I get this information I could identify which are the possible
> problematic ones and work on them. If the process is slow but the query
> is not, maybe the problem would be hidden in the code.

So, there's already some code for timing different parts of the data
loading process, if you look in the job output and search for ", took "
you should see timings printed out.

These timings being printed out does help, but having the information in
the log doesn't make it easy to figure out which part is the slowest for
example.

I'd also not consider this a "one off" thing, the data loading code will
continue to change as Guix changes and it's performance will probably
change too.

I've been wondering about visualisations, I remember systemd had a
feature to plot the systems boot as a image which made seeing which
parts are slow much easier (here's an example [1]).

1: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot001.gif

> About the improvements on the performance of slow parts, it is a little
> bit abstract for me to see now how to break it in smaller tasks. I do
> believe that it would require to reformulate some parts of the queries,
> and as their result may change a bit, tweaks could be required on
> the code too. My point is, how would I propose an improvement approach
> if I don't even know what exactly is to be improved? But I imagine that
> work on this second task is more demanding than the first and will take
> most of the time of the internship.

As I said before, this part is dependent on deciding where the areas for
improvement are. Maybe have a look through one of the job logs on
data.guix.gnu.org and see if you can spot some slow parts?


signature.asc
Description: PGP signature

Outreachy: Timeline tasks

[Luciana Lima Brito]

Hi,

I was thinking about the timeline of tasks.

The main tasks are:

1. Add instrumentation to identify the slow parts of processing
  new revisions

2. Improve the performance of these slow parts

I'm writing some ideas I have to divide the tasks in small steps, see
what you think about it.

About the first task I understand that the whole thing starts with
identifying how the data for new revisions arrives on Guix Data
Service: the relevant queries and their processing on the code. Based
on it I would propose start with mapping these queries and their uses,
so I could run them locally and get their statistics.

Once I get this information I could identify which are the possible
problematic ones and work on them. If the process is slow but the query
is not, maybe the problem would be hidden in the code.

About the improvements on the performance of slow parts, it is a little
bit abstract for me to see now how to break it in smaller tasks. I do
believe that it would require to reformulate some parts of the queries,
and as their result may change a bit, tweaks could be required on
the code too. My point is, how would I propose an improvement approach
if I don't even know what exactly is to be improved? But I imagine that
work on this second task is more demanding than the first and will take
most of the time of the internship.

I appreciate if you could clarify some of these ideas I mentioned.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Leo Famulari]

On Wed, Apr 28, 2021 at 12:43:53PM -0400, Mark H Weaver wrote:
> I'm sorry if this comes off as obtuse, but having now re-read all of my
> messages in this thread, I honestly do not see what I did wrong here.
> I will need some help to understand.

It's common advice that managers and leaders should "praise in public
and criticize in private".

Assuming that the goal of the criticism is to improve somebody's work,
and it must be done in public, then criticism must be carefully
calibrated to avoid making them feel defensive, humiliated, and angry.
It was correct to point out these mistakes in public but, based on the
result, I conclude that your message was not calibrated well.

The beginning of this email discussion began by naming a perpretrator
and pointing out that it was part of a pattern of mistakes, rather than
focusing on the mistake.

The next part said, "Behold [...]". As a native USA English speaker, I
claim that we only use "Behold" ironically and sarcastically.

The message ended by casting aspersions on Raghav's status in Guix.

At no point did you concretely describe the problem, or try to teach
Raghav what the solution was, or try to explain the correct workflow
regarding security updates.

You should have sent a message that explained the problem and tried to
teach the solution. I've seen you do it many times before; I don't know
why you sent that sarcastic and mean message instead.

Meta Guix: why guix is awesome!

[Joshua Branson]

Hello guix developers!

Guix is brilliantly fantastic!  I thought I would write down some of the
things that make guix such a great community and a powerful free
software tool.  I intend this email to encourage guix developers and
perhaps encourage other free software projects to copy guix's success.

1. It encourages non-english speaking participation.  Guix's manual is
   a work of art that has been translated into a few languages:
   German, Spanish, French, Russian, and Chinese?  Honestly my font in
   my browser can't read the last translation...but I think it's
   Mandorin (spelling?)  Anyway, guix has a strong push to NOT be an
   American only project.  It also has some email lists for
   non-english speakers.  That is awesome!  I had never thought about
   non-English mailing lists, but there certainly are non-english
   speakers that would love to get help.  Also the website is
   available many languages.

2. Guix's leadership is non-political.  I recall on the mailing list
   an issue raised about freedom of speech concerns.  Many emotion
   emails went back and forth over this issue with guix developers
   expressing a variety of opinions.  I actually felt encouraged that
   Ludo did NOT say anything in this email exchange.  That signaled to
   me that Ludo doesn't care what your political views are.  Anyone
   and everyone is free to contribute to guix regardless of what you
   believe!

3. It has great marketing.  I think this really ought to be stressed a
   lot!  Guix has numerous blog posts that demonstrate that the
   project is alive.  And they are really well written.  And engaging!
   I absolutely love guix's blog!  And the website is hip!  And it's
   got great artwork!

4.  Some people work full time on guix (and get paid).  There are a
   few guix developers who develop A LOT for guix.  I think the main
   source of income for several prominent guix developers is from
   cluster deployments as seen here: https://hpc.guix.info/about/ Also
   some developers get grants to work for guix as well.  This is a
   personal view, but I do believe that free software ought to somehow
   pay some developers.  That's how they can continue to develop the
   software.

5.  Guix's leadership lets the best idea win.  I personally think
   Ludo's last line on his email is genius: "Thoughts?".  It's a great
   idea to solicit feedback, and I believe that Ludo genuinely wants
   your thought and opinions.

6.  Guix has big goals!  What is org-mode?  Emacs?  Guix?  The
   GNU/Hurd?  All of these projects are sometimes hard to define.
   There are so many things that you can do with guix!  Declarable
   operating system.  Bootstrapped distro.  Portable distro.  Server
   manager.  Soon maybe a guix home manager. This maybe violates the
   unix philosophy of small programs that do things well, but perhaps
   because guix dreams big it can dare crazy things!

7.  Guix is NOT linux development!  Guix encourages newbie developers
   by sometimes fixing their really AWFUL code (or documentation).
   AND NOT being angry at those trivial errors.  For example, some of
   my documentation "fixes" were me pointing out an tiny issue with
   the manual.  Then I sent a diff that didn't work.  And someone else
   submitted a patch on my behalf that did my suggestion.  It's nice
   to know that you won't be needlessly insulted while contributing to
   guix.  A great example of this can be found in the irc log.  I
   recall one such instance of a newbie asking about a silly
   bug/feature.  In a moment of frustration I thought about saying
   something rude (I did not say it).  Ludo actually responded to the
   question with something like, "That's a great point.  Why don't you
   open a bug report here, so that we can properly discuss it?"  That
   was very kind/smart!

Thoughts?

Joshua

P.S.  If this email is not really suited here, please let me know.  I
know I've sent a few emails to guix devel that may not have been
suitable.  Please let me know if that is the case.  :)

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> Léo Le Bouter  writes:
>>
>>> It seems you are more focused and spend more time sending accusations
>>> here than collaboratively working to improve GNU Guix. I don't feel
>>> like that's something great to do at all.
>>
>> I feel an obligation to protect our users, and among other things that
>> means calling attention to Guix committers that are doing things like
>> pushing commits with misleading commit logs (which evade proper review)
>> and pushing "cosmetic changes" that remove security fixes.
>
> That you called attention on these issues is a great service to all of
> us, Mark.  But I have to agree with Ricardo: the harsh accusatory tone
> towards Raghav and Léo was not warranted; please assume good faith.

I'm sorry if this comes off as obtuse, but having now re-read all of my
messages in this thread, I honestly do not see what I did wrong here.
I will need some help to understand.

With very few exceptions, almost every sentence that I wrote was purely
factual.  It seems to me that the facts speak for themselves, and those
facts naturally cast Raghav and Léo in a bad light.  I don't see how to
avoid that while still presenting the facts.

You, and a couple of others, have criticized my "tone".  This is very
subjective, especially over email where we must *imagine* the tone of
the speaker.  Is it possible that you read more in my messages than I
actually wrote?

It would be very helpful if you could point out specific messages or
quotes of mine to illustrate your criticisms, and to clearly explain
what's wrong with them.  I'm not trying to be obstructionist here.  I
honestly don't understand, and I cannot improve without understanding.

 Thanks,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: A "cosmetic changes" commit that removes security fixes

[Marius Bakke]

Léo,

We maintainers have been disappointed by Marks harsh tone which do not
meet the project's communication standards, but also by your apparent
lack of will to reply constructively to legitimate criticism.

This is the next in a series of incidents.  The incidents are okay--we
we all make mistakes and that's how we learn--but we interpreted your
responses all too often as dismissive and defensive, rather than
understanding and forward-looking.  This has been causing unnecessary
friction and stress, and is not how we envision peaceful collaboration.

I'm sorry to say your commit privileges have been temporarily
suspended.  After one month, you are invited to get in touch with the
maintainers collective and discuss next steps.

You have done terrific work in Guix in the short time you've been
around: from the POWER9 port, to the many security fixes,
to tracking and reporting issues, and suggesting improvements to the
tools.  I hope you'll eventually rejoin to collaborate in the peaceful
and empathetic fashion that this project encourages.

-- 
Marius (on behalf of the maintainers collective)


signature.asc
Description: PGP signature

#:cargo-inputs don't honor --with-input

[Hartmut Goebel]

Hi,

FYI: yet another rust issue: #:cargo-inputs don't honor --with-input.

--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Jam: which licence is this?

[Maxim Cournoyer]

Hi Mark,

Mark H Weaver  writes:

> Hi Jack,
>
> Jack Hill  writes:
>
>> I'm working on packaging the Argyll Color Management System for Guix. To 
>> build, it uses the Jam tool, which has the following license:
>>
>> ```
>> This is Release 2.5 of Jam, a make-like program.
>>
>> License is hereby granted to use this software and distribute it
>> freely, as long as this copyright notice is retained and modifications
>> are clearly marked.
>>
>> ALL WARRANTIES ARE HEREBY DISCLAIMED.
>> ```
>>
>> Which license is this?
>
> Thanks very much for your diligence here.
>
> I looked into it, and Debian calls this the "Perforce" license.  The
> "copyright" file for Debian's 'boost' package includes the following
> lines:
>
> License: Perforce
>  License is hereby granted to use this software and distribute it
>  freely, as long as this copyright notice is retained and modifications
>  are clearly marked.
>  .
>  ALL WARRANTIES ARE HEREBY DISCLAIMED.
>
> 
>
> Maybe this should be added to (guix licenses) as 'perforce', or perhaps
> 'perforce-jam'?

Unless that license is commonly used enough, I would rather not bloat
the licenses list in Guix and instead use the non-copyleft procedure to
define it on the spot, if needed.

Does that make sense?

Maxim

Re: Outreachy - Guix Data Service: questions about improving the data for derivation comparisons.

[Christopher Baines]

Luciana Lima Brito  writes:

> Hi,
>
> On Tue, 27 Apr 2021 21:29:35 +0100
> Christopher Baines  wrote:
>
>
>> Great :) I've tweaked the commit message a little and pushed.
>
> This is really great!!!
>
> I started to look after my final application and I need to see two
> specific things with you to finish filling the forms.
>
> 1 - There is a field in which I should provide more information, if
> required by the community or project's mentor. Are there any questions
> I should answer?

Nope, you can leave that bit.

> 2 - About the timeline: "work with your mentor to provide a timeline of
> the work you plan to accomplish on the project and what tasks you will
> finish at each step".

This is relevant though. I'd say the important bit of what's above is
the breakdown of the work (the tasks) as you see it, rather than any
exact dates in the timeline.

So, have another read of the project description and the main tasks as I
set out. Now is the time to discuss if that approach makes sense, and
once you're happy with the direction, start to split tasks down in to
more concrete parts.

I realise the performance improvements will be dependent on the
discovery work, so this more applies to the approach to work out what
bits are slow. I can try and help with this, but it's not me who's going
to be doing the work, so it's you who needs to be happy with the
proposed approach.

> another thing, what I should be doing now for my next contribution?

Given the final application deadline is quite close, I'd look at that
first.

Chris


signature.asc
Description: PGP signature