Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Thu, Feb 15 2024, Simon Tournier wrote:

> Hi Clément,
>
> If read correctly, you answered about Gnus (debbugs.el):
>
 --8<---cut here---start->8---
 (with-current-buffer gnus-original-article-buffer
   (message-fetch-field "Message-ID"))
 --8<---cut here---end--->8---
>
> [...]
>
 May I add too, that you can add "Message-ID" in gnus-visible-headers.
>
> [...]
>
>> You add '%M' in gnus-summary-line-format.
>
> [...]
>
>> Yes it does provide a built-in access, as I showed you.  Just search for
>> "Message-id" in `C-h v gnus-summary-line-format`.
>
> And my message was:
>
>   What appears to me “difficult” is that most of the
>  tools as Email client are poorly supporting Message-ID.

I didn't reply to this, but to your debbugs.el (gnus) example,
explaining how Message-ID was well supported.

> Somehow, the reader will judge if Message-ID is smoothly supported. :-)

Ok, yes.  Good night Simon :)

Clément

Re: Mechanism for helping in multi-channels configuration

[Simon Tournier]

Hi Attila,

On mar., 06 févr. 2024 at 17:16, Attila Lendvai  wrote:
>> The wishlist is: provide a machine-readable description on guix-science
>> channel side in order to help in finding the good overlap between
>> commits of different channels.
>
> i wrote about a missing abstraction here:
>
> https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00104.html

You wrote in [1]:

it's probably the same thing that causes the discrepancy between
git commits and substitutes: the build servers are not building
every commit of the git repo. they pick an unpredictable (?)
series of commits, skipping some in between.  if i guix pull, or
guix time-machine to the "wrong" commit, then i'll need to build
some stuff locally. sometimes these can be heavy packages.

To my knowledge:

 + ci.guix (Cuirass) fetches every 5 minutes (IIRC) and builds the last
   commit.

 + bordeaux.guix (Build Coordinator) fetches the batch from the mailing
   list guix-commits:
   

About CI, yes it is unpredictable.  About Bordeaux, it is not really. :-)

1: Re: Should commits rather be buildable or small
Attila Lendvai 
Sun, 10 Dec 2023 23:20:25 +
id:SXjFmdTgxwHYE-Z6t7SZOykuXMBiD454EF2uad96jGQemgJ6hXki_f1C7VxVHKHa4b7_j5UwJmffh_FiQqEz_bIYIBn9tpG4s9F7W1eIDAQ=@lendvai.name
https://lists.gnu.org/archive/html/guix-devel/2023-12
https://yhetil.org/guix/SXjFmdTgxwHYE-Z6t7SZOykuXMBiD454EF2uad96jGQemgJ6hXki_f1C7VxVHKHa4b7_j5UwJmffh_FiQqEz_bIYIBn9tpG4s9F7W1eIDAQ=@lendvai.name

> the git commit log is a too fine-grained granularity here. there
> should be something like a 'guix log' above the git log that could be
> used, among other things, to encode inter-channel dependencies.

Considering the current status and how substitutes are GC, the first
step would be the retention of some substitutes.  And thus the
specification for a policy of such retention.  It would allow to build a
database that could be queried by this hypothetical “guix log” – which
should be more something under “guix weather” IMHO.

For the interested readers, thread about retention:

Building and caching old Guix derivations for a faster time machine
Ricardo Wurmus 
Fri, 10 Nov 2023 10:29:28 +0100
id:87o7g29c94@elephly.net
https://lists.gnu.org/archive/html/guix-devel/2023-11
https://yhetil.org/guix/87o7g29c94@elephly.net

Substitute retention
Ludovic Courtès 
Tue, 12 Oct 2021 18:04:25 +0200
id:87y26ytek6.fsf...@inria.fr
https://lists.gnu.org/archive/html/guix-devel/2021-10
https://yhetil.org/guix/87y26ytek6.fsf...@inria.fr

Although I concur with this need, I do not see how it would be help for
detecting compatibility between channels. :-)

Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Clément,

If read correctly, you answered about Gnus (debbugs.el):

>>> --8<---cut here---start->8---
>>> (with-current-buffer gnus-original-article-buffer
>>>   (message-fetch-field "Message-ID"))
>>> --8<---cut here---end--->8---

[...]

>>> May I add too, that you can add "Message-ID" in gnus-visible-headers.

[...]

> You add '%M' in gnus-summary-line-format.

[...]

> Yes it does provide a built-in access, as I showed you.  Just search for
> "Message-id" in `C-h v gnus-summary-line-format`.

And my message was:

  What appears to me “difficult” is that most of the
 tools as Email client are poorly supporting Message-ID.

Somehow, the reader will judge if Message-ID is smoothly supported. :-)

Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Felix,

On jeu., 15 févr. 2024 at 07:32, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> To request a feature in Debbugs.el, please file a bug against the
> "debbugs.gnu.org" package on debbugs.gnu.org.

To be clear, my message [1] was not to report a “bug” or request for a
“feature” in debbugs.el.  My message was:

  What appears to me “difficult” is that most of the
tools as Email client are poorly supporting Message-ID.

For instance,

And I took as one example the venerable debbugs.el for making my point:
most of the tools that deal with Emails poorly support one key of Email
heart: Message-ID.

Personally, I rely on the cool piem.el and some custom Emacs lisp
helpers, then for dealing with complex patch or bug thread, I inject and
process them with notmuch.el. :-)

Therefore, open a feature request is low on my list of TODO. ;-)

Cheers,
simon

1: Re: Guix Days: Patch flow discussion
Simon Tournier 
Wed, 14 Feb 2024 16:48:07 +0100
id:87mss3kpxk@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-02
https://yhetil.org/guix/87mss3kpxk@gmail.com

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Thu, Feb 15 2024, Simon Tournier wrote:

> Hi Clément,
>
> On jeu., 15 févr. 2024 at 12:45, Clément Lassieur  
> wrote:
>
 'b4 shazam' is probably the most trouble-free way to apply patches;
>>>
>>> I agree*!
>>
>> I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and
>> allow to apply a range of n patches at once) but I don't think there is
>> a need for competition here, it's good that we have several tools.
>
> Yes for sure it is good to have several tools.  And the ones you like. :-)
>
> No one is advocating to make ’b4 shazam’ THE only one tool.
>
> Instead, I agree with Maxim that exposing Message-ID and relying on ’b4
> shazam’ is the most trouble-free and config-less way to apply patches.

I know ;)

>>>  What appears to me “difficult” is that most of the
>>> tools as Email client are poorly supporting Message-ID.
>>>
>>> For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
>>> to get the Message-ID when reading an article (bug/patch) from Debbugs.
>>> There is other means for applying patches.  But still each time appears
>>> to me weird. :-)
>>
>> It's
>>
>> --8<---cut here---start->8---
>> (with-current-buffer gnus-original-article-buffer
>>   (message-fetch-field "Message-ID"))
>> --8<---cut here---end--->8---
>
> [...]
>
>> May I add too, that you can add "Message-ID" in gnus-visible-headers.
>
> And what about Summary buffer?

You add '%M' in gnus-summary-line-format.

> Well, it makes my point, no? :-)

No, it doesn't :-)

> For sure the Message-ID is there and for sure it is possible to extract
> it.  However, it appears to me weird that it is not built-in.  I mean
> Message-ID is one of the heart of Emails, and Debbugs is just Emails,
> but debbugs.el does not provide a built-in access to it.

Yes it does provide a built-in access, as I showed you.  Just search for
"Message-id" in `C-h v gnus-summary-line-format`.

Cheers,
Clément

Re: Golang check phase skipping some tests?

[Simon Tournier]

Hi,

On jeu., 15 févr. 2024 at 10:10, Sharlatan Hellseher  
wrote:

> I would push go-team branch to check some lower level modifications to
> go-build-system which are queued right now. I need someone with admin access 
> to
> set the branch on CI as well ;-)

Cool!  Thank you.

Cheers,
simon

Re: Mechanism for helping in multi-channels configuration

[Simon Tournier]

Hi Christina,

On sam., 03 févr. 2024 at 15:27, Christina O'Donnell  wrote:

>   1. Have a script that scrapes all the define-public symbols in every 
> file in
>      every package.

I think you mean ’fold-packages’.

>   2. Have a script that determines the symbols needed by each file. (Macros
>      make this more difficult, but.)

Well, this would be difficult, IMHO.  Somehow, it is what the compiler
does. :-)

>   3. Have both scripts have an incremental version that runs on diffs (for
>      performance).
>   4. Run this for every commit on every branch on every channel caching the
>      result.
>   5. Have a CI script keep this updated for new commits.
>   6. Have a server track incompatibilities.

Here, I think the issue is that one server needs to track all the
channels.  And that’s a too strong assumption, IMHO.

I think the design should be something on channel maintainer side.
Somehow, the main Guix channel could be seen as a Git submodule from the
channel side and the issue is that information is not tracked.

There is this ’.guix-channel’ file which allows to describe channel
dependencies.  And the improvements could be to add more there.  The
question is what to add and how to add it.  Keeping in mind the
simplicity and the maintenance burden-free. :-)


> Full disclosure: I've got nothing lined up for the summer yet, so I'm on the
> prowl for GSoC projects :)

Cool!

In that spirit, one tool that is missing is: search packages in all the
history. Somehow the need is described by this message [1]: how to find
which Guix revision provides which version of Foo?

In addition, “guix search” is slow [2].

Well, I have started the embryo of an extension based on Guile-Xapian
for indexing and improving the search.  Really an embryo. :-)

I think this would fit some GSoC. ;-)


Cheers,
simon

1: Re: List available versions of package.
Philippe Veber 
Tue, 11 Jun 2019 09:43:08 +0200
id:CAOOOohSzUezKvm=ro0bxrgh3m0eo2x0cotvd--varxwoqtc...@mail.gmail.com
https://lists.gnu.org/archive/html/help-guix/2019-06
https://yhetil.org/guix/CAOOOohSzUezKvm=ro0bxrgh3m0eo2x0cotvd--varxwoqtc...@mail.gmail.com

2: https://issues.guix.gnu.org/issue/39258

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Josselin,

On jeu., 15 févr. 2024 at 12:07, Josselin Poiret  wrote:

> I think b4's ML is more active than the GitHub issues, I have already
> sent some bug reports and patches there that were picked up quite fast.

Yeah, Kyle pointed me that out months ago.  Then I have never taken the
time to report there. :-)

Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Clément,

On jeu., 15 févr. 2024 at 12:45, Clément Lassieur  wrote:

>>> 'b4 shazam' is probably the most trouble-free way to apply patches;
>>
>> I agree*!
>
> I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and
> allow to apply a range of n patches at once) but I don't think there is
> a need for competition here, it's good that we have several tools.

Yes for sure it is good to have several tools.  And the ones you like. :-)

No one is advocating to make ’b4 shazam’ THE only one tool.

Instead, I agree with Maxim that exposing Message-ID and relying on ’b4
shazam’ is the most trouble-free and config-less way to apply patches.


>>  What appears to me “difficult” is that most of the
>> tools as Email client are poorly supporting Message-ID.
>>
>> For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
>> to get the Message-ID when reading an article (bug/patch) from Debbugs.
>> There is other means for applying patches.  But still each time appears
>> to me weird. :-)
>
> It's
>
> --8<---cut here---start->8---
> (with-current-buffer gnus-original-article-buffer
>   (message-fetch-field "Message-ID"))
> --8<---cut here---end--->8---

[...]

> May I add too, that you can add "Message-ID" in gnus-visible-headers.

And what about Summary buffer?

Well, it makes my point, no? :-)

For sure the Message-ID is there and for sure it is possible to extract
it.  However, it appears to me weird that it is not built-in.  I mean
Message-ID is one of the heart of Emails, and Debbugs is just Emails,
but debbugs.el does not provide a built-in access to it.


Cheers,
simon

Re: Guix Days: Patch flow discussion

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

Hi Simon,

On Thu, Feb 15 2024, Clément Lassieur wrote:

> May I add too, that you can add "Message-ID" in gnus-visible-headers.

The author of Debbugs.el, Michael Albinus, said this was likely the best
solution.

To request a feature in Debbugs.el, please file a bug against the
"debbugs.gnu.org" package on debbugs.gnu.org. Thanks!

Kind regards
Felix

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Thu, Feb 15 2024, Clément Lassieur wrote:

> Hey Simon!
>
> On Wed, Feb 14 2024, Simon Tournier wrote:
>
>> Hi,
>>
>> On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer  
>> wrote:
>>
>>> 'b4 shazam' is probably the most trouble-free way to apply patches;
>>
>> I agree*!
>
> I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and
> allow to apply a range of n patches at once) but I don't think there is
> a need for competition here, it's good that we have several tools.
>
>>> it
>>> even selects the latest revision it finds in the issue thread.  To make
>>> finding a message-id easier, I've also recently added a 'Copy
>>> Message-ID' button to the Mumi interface; try it visiting any issue,
>>> e.g. .  The message-id of any message
>>> can be easily copied to your clipboard via the new button.
>>
>> I also agree! :-) What appears to me “difficult” is that most of the
>> tools as Email client are poorly supporting Message-ID.
>>
>> For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
>> to get the Message-ID when reading an article (bug/patch) from Debbugs.
>> There is other means for applying patches.  But still each time appears
>> to me weird. :-)

May I add too, that you can add "Message-ID" in gnus-visible-headers.

>
> It's
>
> (with-current-buffer gnus-original-article-buffer
>   (message-fetch-field "Message-ID"))
>
> Cheers
> Clément

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

Hey Simon!

On Wed, Feb 14 2024, Simon Tournier wrote:

> Hi,
>
> On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer  
> wrote:
>
>> 'b4 shazam' is probably the most trouble-free way to apply patches;
>
> I agree*!

I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and
allow to apply a range of n patches at once) but I don't think there is
a need for competition here, it's good that we have several tools.

>> it
>> even selects the latest revision it finds in the issue thread.  To make
>> finding a message-id easier, I've also recently added a 'Copy
>> Message-ID' button to the Mumi interface; try it visiting any issue,
>> e.g. .  The message-id of any message
>> can be easily copied to your clipboard via the new button.
>
> I also agree! :-) What appears to me “difficult” is that most of the
> tools as Email client are poorly supporting Message-ID.
>
> For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
> to get the Message-ID when reading an article (bug/patch) from Debbugs.
> There is other means for applying patches.  But still each time appears
> to me weird. :-)

It's

--8<---cut here---start->8---
(with-current-buffer gnus-original-article-buffer
  (message-fetch-field "Message-ID"))
--8<---cut here---end--->8---

Cheers
Clément

Re: Guix Days: Patch flow discussion

[Josselin Poiret]

Hi Simon,

Simon Tournier  writes:

> PS: *agree on B4 although there is tricky bugs as reported here:
> .

I think b4's ML is more active than the GitHub issues, I have already
sent some bug reports and patches there that were picked up quite fast.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Debugging missing architecture support

[Konrad Hinsen]

Hi Saku,

> Maybe someone else can give more general or Guix specific advice on
> finding out the cause of such problems, but I believe that in this case
> the fix would just be packaging GHC for aarch64-linux. It should[1] be
> possible but it will require some work.
>
> [1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms

Thanks for the pointer! It looks indeed like GHC already support
aarch64, so it's just a matter of integrating that support into Guix.
I'll see if I can find someone motivated and competent to do that.

Cheers,
  Konrad

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi Simon!

> What is the status of this?  Is all fine?

There are new modules available which I use for moving packages from golang.scm
and other places e.g. syncthing.scm.

- golang-build.scm
- golang-check.scm
- golang-compression.scm
- golang-crypto.scm
- golang-web.scm
- golang-xyz.scm

I would push go-team branch to check some lower level modifications to
go-build-system which are queued right now. I need someone with admin access to
set the branch on CI as well ;-)

Thanks,
Oleg

-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Debugging missing architecture support

[Konrad Hinsen]

Ricardo Wurmus  writes:

> You can try this in guix repl:
>
> --8<---cut here---start->8---
> (import (srfi srfi-1)
> (guix packages)
> (gnu packages))
>
> (define p (specification->package "git-annex"))
> (define deps (package-development-inputs p))
> (find (lambda (pkg)
> (not (member "aarch64-linux" (package-supported-systems pkg
>   (map cadr deps))
> --8<---cut here---end--->8---

Thanks, that's very useful!

I changed the last command to

--8<---cut here---start->8---
(find (lambda (pkg)
(and (package? pkg)
 (not (member "aarch64-linux" (package-supported-systems pkg)
  (map cadr deps))
--8<---cut here---end--->8---

because some packages have local files among the development inputs.

This search doesn't work for all cases though. For "python-jupyterlab"
(from the guix-science channel) it returns no problematic dependencies,
and yet I cannot build the package for aarch64-linux.

The problem in that case seems to be cross-compilation. The dependency
of python-jupyterlab that fails to build is libwebp, whose build log
says:

   @ unsupported-platform 
/gnu/store/7fj9ckgxw27r196vkisc9cm3n8v9072x-libwebp-1.3.2.drv aarch64-linux
   while setting up the build environment: a `aarch64-linux' is required to
   build `/gnu/store/7fj9ckgxw27r196vkisc9cm3n8v9072x-libwebp-1.3.2.drv',
   but I am a `x86_64-linux'

Maybe this would build on an actual ARM64 machine.

Cheers,
  Konrad.

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi,

On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer  
wrote:

> 'b4 shazam' is probably the most trouble-free way to apply patches;

I agree*!

> it
> even selects the latest revision it finds in the issue thread.  To make
> finding a message-id easier, I've also recently added a 'Copy
> Message-ID' button to the Mumi interface; try it visiting any issue,
> e.g. .  The message-id of any message
> can be easily copied to your clipboard via the new button.

I also agree! :-) What appears to me “difficult” is that most of the
tools as Email client are poorly supporting Message-ID.

For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
to get the Message-ID when reading an article (bug/patch) from Debbugs.
There is other means for applying patches.  But still each time appears
to me weird. :-)

So thanks for this Mumi addition!

Cheers,
simon

PS: *agree on B4 although there is tricky bugs as reported here:
.

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Steve,

  ( On a side note, the triage of old bugs is a similar problem.  They
are easy to find [2], read, check and send an email to
12...@debbugs.gnu.org does not appear to me an issue with any tool.

For what it is worth and without any willing of being harsh, I am
able to count the people doing this boring task.

What is hard to solve is the incentives for doing the boring, but
necessary, collective tasks.

Bah the usual problem of lengthy discussions with roommates in any
shared apartment: who clean the bathroom? :-) )


On lun., 05 févr. 2024 at 09:39, Steve George  wrote:

> Our goal for the discussion:
>
>   How do we double the number of patches that are *reviewed* and
>   *applied* to Guix in the next six months?

Thanks for these notes and leading the session.  On my side, it was a
fruitful discussion.

Well, let me try to quickly summarize my conclusion of the session:

 1. We have a social/organisational problem.

 2. We have some tooling annoyances.



The easy first: #2 about tools.  The email workflow is often cited as
part of the issue.  That’s a false-problem, IMHO.

Projects that use PR/MR workflow have the same problem.  For instance,
Julia [1] has 896 open PR.  On my browser, it means 36 pages so if I go
to – 25 PRs per page – the still open submitted PRs:

   + the 6th page:  around Sept.2023 and Oct. 2023
   + the 12th page: around Apr. 2023 and Mar. 2023
   + the 18th page: around Jul. 2022 and Mar. 2022
   + the 24th page: around Jun. 2021 and May  2021
   + the 30th page: around Mar. 2020 and Oct. 2019
   + the 36th page: around Mar. 2017 and May. 2014

Obviously, an example is not a proof or an evidence.  It is just a
first clue. :-)

I will not speak about the channel ’nonguix’ but it gives another
clue.

That said, for sure, the tools need more love.  Thanks all the people
for all hard work over the years in this area – no name, you know, I
fear to forget someone. ;-)

So, yeah we need to smooth the technical burden for reviewing in order
to focus on the review itself.

To be clear, the email workflow might add burden on submitter side but I
am doubtful it is really part of the bottleneck for reviewing and
pushing submissions.


Although the tools might add some unnecessary friction, the net of the
issue is IMHO #1: reviewing is just boring and time-consuming.

Who feel accountable?  And for what?  That’s the question, IMHO.

If the number of submission is doubled, how do we increase the number of
people that feel enough accountable for doing the boring work?

  ( Maybe accountable is not the correct word.  Obligation neither.
Well the kind of feeling that is okish if you skip the task but you
know it will be better if you do it. )


Well, the difficult part is not pressing some buttons for merging and
pushing – whatever the tools or workflow.  The difficult part is to
scrutinize the submission.

I think the bottleneck is not the number of people able to push.
Instead, I think the bottleneck is the number of people confident with
the change for then pushing it.

The question is thus: how to build this confidence?


Look, when a committer has some free-time, most of the time, what is the
process: take first the “easy“ submissions for committing them – from
trivial updates to simple updates.  If free-time remains, then engage
with more “complex” submissions… ah no more free-time. :-)

Why starting by the “easy” submission?  Because it is less boring and
time-consuming; somehow it is easier to feel confident with that sort of
change for pushing it.

As a rule of thumb, about the time it takes – on average –, the order of
magnitude for reviewing is similar as the one for submitting.  Well,
from my experience and although I never did stats. :-)


All in all, I see two paths to move forward:

i) Non-committers can help.  On two fronts:

   + Answer to submitter with the changes for being compliant with Guix
 standards.
   
   + Follow-up on patches already commented but without an updated
 revision: upgrade the re-roll count by sending this revision.

 It eases for merging if I do not have to make many tiny edits
 myself.

ii) Create more teams or at least more people should commit to be part
of a team and help in reviewing what they know.

For instance, since Sept. (167 days ago) I have been CC in 108
patches submissions.  Most of them are from ’core’ team that I would
qualify as “complex”. :-)

Many patches assigned to ’core’ team are sent by committers.  The
issue is not being a committer or not.  Instead, being more eyes
commenting would increase the confidence.  Thus it would reduce the
workload.

That’s the same for any team, IMHO.

And I do not speak about patches that are not assigned to any team.


Somehow, we need to think how people would feel “accountable” for doing
the collective tasks with low, no direct or personal reward.

As with many non-technical 

Re: Git-LFS or Git Annex?

[Simon Tournier]

Hi Timothy,

On sam., 27 janv. 2024 at 10:59, Timothy Sample  wrote:

> https://git.ngyro.com/git-annex-remote-clouda/tree/git-annex-remote-clouda/remote.scm

Oh cool, thanks.  Bookmarked.

Cheers,
simon

Re: Golang check phase skipping some tests?

[Simon Tournier]

Hi,

Late to the party. :-)  Processing my backlog…

On jeu., 18 janv. 2024 at 10:25, Sharlatan Hellseher  
wrote:

> I'm currently in review and split some packages from (gnu packages golang) 
> into
> (gnu packages golang-crypto) to simplify the maintenance. I try to play with
> that option and see which packages are missed to satisfy passing all tests.

What is the status of this?  Is all fine?

Cheers,
simon

Re: Committers available for Patch hacking/review meet-up?

[Simon Tournier]

Hi,

On mar., 13 févr. 2024 at 14:48, Steve George  wrote:

> At Guix Days we said we'd organise some patch review sessions.

Cool!


> Anyone available? If you are and can put your name down for a particular 
> date that would be brilliant!

I will do.  Thanks for the initiative!


> Q2: Does anyone have permission on 
> https://libreplanet.org/wiki/Group:Guix to give a user the right to 
> create new pages? I want to document the sessions and how-to's.

Hum, I do not know who did it and how… there is this webpage:

https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024


> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20240213=5416=136=179

Is Annecy time the same as Paris time? ;-)


Cheers,
simon

Re: Committers available for Patch hacking/review meet-up?

[Steve George]

On 15/02/2024 00:53, jgart wrote:

7th March (Thursday)
20th March (Wednesday)
2nd April (Tuesday)
15th April (Monday)
3rd May (Friday)
16th May (Thursday)
29th May (Wednesday)

Each one held at 19:00 CET / 18:00 BST / 13:00 EST [0] for 1.5 hours.


Hi,

Thanks for putting this together.

Lately I've been too busy with work and other tasks/priorities to review Guix 
patches, unfortunately.

Those dates and times conflict with my work hours so I probably won't be able 
to attend any of the proposed dates.

I live in the CT timezone and I am usually working from 9 AM to 5 or 6 PM CT on 
weekdays.

I could potentially do a Saturday or Sunday sometime in May.

all best,

jgart

https://whereis.みんな/


Hi Jgart - understood and no worries - sorry about the timing, hard to 
find something that works for everyone. If you don't mind I'll email you 
a bit closer to May and see what your calendar is like - then we can see 
if organising something on a weekend or maybe recording a video would be 
possible.


Thanks,

Steve

Re: Committers available for Patch hacking/review meet-up?

[Steve George]

Hi Andreas,

On 14/02/2024 14:04, Andreas Enge wrote:

Hello,

thanks, Steve, for getting things going!

Am Tue, Feb 13, 2024 at 02:48:08PM + schrieb Steve George:

We said they'd be every 13 days, for 3 months to see if it has interest.
Proposed calendar:
7th March (Thursday)


I will be around on this day.



That's brilliant - thanks so much!


Each one held at 19:00 CET / 18:00 BST / 13:00 EST [0] for 1.5 hours.


For these, we will have the daylight savings time switch; so maybe we
should move to 19:00 CEST. Something we can do later.



Argh!


What I propose is that we'd do the following:
1 - 30 mins: a committer runs through their review process, and shows a
recent patch or patches they've reviewed. Really informal showing what they
do.


Well, I only ever look at simple packages, and do not think I have anything
resembling a process to share. But I will try to be around in any case :)

(...)

Understood, any tips, tricks or any thoughts are going to be welcome!

Steve