Re: Maintenance and future of Guile

Re: Maintenance and future of Guile

[Blake Shaw]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> Olivier Dion via "Developers list for Guile, the GNU extensibility
> library" <guile-devel@gnu.org> writes:
>
>>> irc is good for me, and of course e-mail :)
>>>
>>> but for out-of-the-box task management tools, are we all emacs
>>> and/or org-mode users
>>> here? we could agree on a set of features for an org document that
>>> ensures
>>> we all sync consistentally across configurations, and then manage
>>> everything on a
>>> branch of the guile repo. this way as we're researching the codebase, we
>>> can post links directly to file line numbers, allowing easy
>>> navigation.
>>
>> I'm fullstack emacs, but I'm not sure if org-mode would be the best
>> management tool.  I'm using it for my personnal task, but I don't know
>> if it applies well to a team.
>
I get what you're saying, but considering we are an informal team of
emacs users, I think it could make sense. Otherwise we'll either all
need to get in the habit of using some new task-management platform
(easier said than done), or someone will need someone to step-up as an
"Agile Coach" or whatever to make sure we all gently settle into it. 

If we're all dedicated emacsians, it could be as simple as setting up
cron jobs to pull at regular intervals, and could shed some insight onto
"guix native" development and its challenges. 
> I’m using it for my personal tasks, too, but I think when syncing the
> file across people and including it in the agenda, that gives a pretty
> good team management.
>
> I got reports of people using my kanban.el for team management.

Nice you made that! All the more reason for use to give it a shot I
think. This could give you some nice insight into where it succeeds and
fails, as well.
> I’m not sure whether full org-mode is the best for Guile development,
> but it does work pretty well, and I think it would be worth a try.
>
> We can ket all kinds of useful public statistics by publishing a static
> site from the org documents.
Very true. I don't know any other tool that makes all of this easy.
>
> Best wishes,
> Arne

-- 
“In girum imus nocte et consumimur igni”

Re: Maintenance and future of Guile

[Olivier Dion via Developers list for Guile, the GNU extensibility library]

On Thu, 30 Dec 2021, Blake Shaw <blake@nonconstructivism.com> wrote:
> If we're all dedicated emacsians, it could be as simple as setting up
> cron jobs to pull at regular intervals, and could shed some insight onto
> "guix native" development and its challenges.

If it's okay with everyone, I think that would be awesome.  Given what
Dr. Arne said, I think we can use it for management of the team.

The next things to do (none exhaustive) I guess would be:

  1. Make a list of contributors that want to participate
  2. Make a a list of what's to be done and in which priority
  3. Setup the management workflow with org-mode and distribute the work
  among contributors

P.S: I'm not sure why, but when you reply (Blake), there's another
mail chain spawning in my MUA instead of following the previous chain.  It's
nothing concerning, but it does break the flow of mail conversation.

-- 
Olivier Dion
Polymtl

Re: Maintenance and future of Guile

[Blake Shaw]

Tim Van den Langenbergh <tmt_vdl@gmx.com> writes:
> That sounds like a good idea, though I wonder what the best way to organise it would be.
>
> IRC, Mattermost, and Rocket Chat seem like the most obvious options
> for chat. I don't know what would be best for task management, maybe
> some out-of-the-box kanban?
>
> Ideas, anyone?
>
> Vale,
>
> -Tim.
>

irc is good for me, and of course e-mail :)

but for out-of-the-box task management tools, are we all emacs and/or org-mode users
here? we could agree on a set of features for an org document that ensures
we all sync consistentally across configurations, and then manage everything on a
branch of the guile repo. this way as we're researching the codebase, we
can post links directly to file line numbers, allowing easy navigation.

-- 
“In girum imus nocte et consumimur igni”

Re: Maintenance and future of Guile

[Olivier Dion via Developers list for Guile, the GNU extensibility library]

On Tue, 21 Dec 2021, Blake Shaw <blake@nonconstructivism.com> wrote:
> Tim Van den Langenbergh <tmt_vdl@gmx.com> writes:
>> That sounds like a good idea, though I wonder what the best way to organise it would be.
>>
>> IRC, Mattermost, and Rocket Chat seem like the most obvious options
>> for chat. I don't know what would be best for task management, maybe
>> some out-of-the-box kanban?
>>
>> Ideas, anyone?
>>
>> Vale,
>>
>> -Tim.
>>
>
> irc is good for me, and of course e-mail :)
>
> but for out-of-the-box task management tools, are we all emacs and/or org-mode users
> here? we could agree on a set of features for an org document that ensures
> we all sync consistentally across configurations, and then manage everything on a
> branch of the guile repo. this way as we're researching the codebase, we
> can post links directly to file line numbers, allowing easy
> navigation.

I'm fullstack emacs, but I'm not sure if org-mode would be the best
management tool.  I'm using it for my personnal task, but I don't know
if it applies well to a team.

-- 
Olivier Dion
Polymtl

Re: Maintenance and future of Guile

[Dr. Arne Babenhauserheide]

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


Olivier Dion via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org> writes:

> On Tue, 21 Dec 2021, Blake Shaw <blake@nonconstructivism.com> wrote:
>> Tim Van den Langenbergh <tmt_vdl@gmx.com> writes:
>>> That sounds like a good idea, though I wonder what the best way to organise it would be.
>>>
>>> IRC, Mattermost, and Rocket Chat seem like the most obvious options
>>> for chat. I don't know what would be best for task management, maybe
>>> some out-of-the-box kanban?
>>>
>>> Ideas, anyone?
>>>
>>> Vale,
>>>
>>> -Tim.
>>>
>>
>> irc is good for me, and of course e-mail :)
>>
>> but for out-of-the-box task management tools, are we all emacs and/or org-mode users
>> here? we could agree on a set of features for an org document that ensures
>> we all sync consistentally across configurations, and then manage everything on a
>> branch of the guile repo. this way as we're researching the codebase, we
>> can post links directly to file line numbers, allowing easy
>> navigation.
>
> I'm fullstack emacs, but I'm not sure if org-mode would be the best
> management tool.  I'm using it for my personnal task, but I don't know
> if it applies well to a team.

I’m using it for my personal tasks, too, but I think when syncing the
file across people and including it in the agenda, that gives a pretty
good team management.

I got reports of people using my kanban.el for team management.

I’m not sure whether full org-mode is the best for Guile development,
but it does work pretty well, and I think it would be worth a try.

We can ket all kinds of useful public statistics by publishing a static
site from the org documents.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

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

Re: Maintenance and future of Guile

[Blake Shaw]

Taylan Kammer <taylan.kammer@gmail.com> writes:

> On 17.12.2021 16:48, Olivier Dion wrote:
>>> Olivier Dion <olivier.dion@polymtl.ca> skribis:
>>>
>>>> I would also like to contribute in some meaningful way.  In what way
>>>> someone with none wizard knowledge of Scheme can contribute the most to the
>>>> project?
>>>
>> On Fri, 17 Dec 2021, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Triage of bugs and patches is always welcome I guess, and communicating
>>> what needs to be applied/addressed first to whoever can actually commit
>>> it.  That’s one possible way to help.
>> 
>> Where can this be done?  I know that Guix is using debbugs, but do Guile
>> does the same or is it all tracked on Savannah?
>> 
>> Also, any way to help on the C side?
>> 
>
> Guile also uses Debbugs:
>
> https://bugs.gnu.org/guile

hi folks, from what I'm seeing here it seems like there are quite a few
of us who are interested in engaging in steady, organized participation
in Guile's upkeep, but we're unsure whether we're qualified. At the same
time Ludo needs to find a replacement and Andy is apparently quite busy,
and some issues in the ecosystem are apparently starting to show their teeth.

personally I've been programming for about 15 years now but my career
has been entirely in new media (video, graphics, audio), so while I've
worked with plenty of lower-level libraries over the years, I didn't
start to get an itch for compilers until covid happened. I was also
doing a PhD in philosophy of mathematics at the time (which I've
postponed indefinitely to prevent being separated from my partner during 
covid travel craziness) so I definitely think I have the *potential* to
contribute to a project like Guile, its just a matter of finding the
time to read some compiler books (which usually are neither short nor easy!).

It sounds like others are coming from similar-ish places: you feel
confident in your abilities to accede to the challenges, but lack the
background that would enable you to take the initiative. So what are we
TODO?

In a situation like this, I would recommend that we form a little
working group to collectively study the implementation of Guile, and
with Ludo's suggestions come up with a roadmap for tackling various areas
of the repo/compiler/infrastructure that need work, which we could then
divide up among ourselves with each of us creating a presentation on our
assigned areas, with group hack sessions following each bi-weekly (or
whatever) presentation. This way we could distribute the knowledge
aquisicition work in a structured fashion while forming a support group for
developing a collective understanding of the codebase, as a cohort of
sorts.  
 
wdyt?

ez,
blake 

-- 
“In girum imus nocte et consumimur igni”

Re: Maintenance and future of Guile

[Maxime Devos]

Hi,

Blake Shaw schreef op ma 20-12-2021 om 03:05 [+0700]:
> personally I've been programming for about 15 years now but my career
> has been entirely in new media (video, graphics, audio), so while
> I've
> worked with plenty of lower-level libraries over the years, I didn't
> start to get an itch for compilers until covid happened. I was also
> doing a PhD in philosophy of mathematics at the time (which I've
> postponed indefinitely to prevent being separated from my partner
> during 
> covid travel craziness) so I definitely think I have the *potential*
> to
> contribute to a project like Guile, its just a matter of finding the
> time to read some compiler books (which usually are neither short nor
> easy!).

I want to note that, while definitely the compiler part is an important
part of Guile, there's plenty of non-compiler and non-language things
in Guile as well, so reading compiler books should be unnecessary to
contribute to Guile.

E.g., things like getopt
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32154),
the HTTP API (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43711),
a bug fix in the test suite
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43521) (verified to
work, for almost a year!).

Anyway, I would like to help when I get back to hacking, although I'd
have a (non-Guile) backlog to work through first, and there would be
some other projects I'd be working on as well.

Greetings,
Maxime.

Re: Maintenance and future of Guile

[Olivier Dion via Developers list for Guile, the GNU extensibility library]

On Mon, 20 Dec 2021, Blake Shaw <blake@nonconstructivism.com> wrote:
> In a situation like this, I would recommend that we form a little
> working group to collectively study the implementation of Guile, and
> with Ludo's suggestions come up with a roadmap for tackling various
> areas of the repo/compiler/infrastructure that need work, which we
> could then divide up among ourselves with each of us creating a
> presentation on our assigned areas, with group hack sessions following
> each bi-weekly (or whatever) presentation. This way we could
> distribute the knowledge aquisicition work in a structured fashion
> while forming a support group for developing a collective
> understanding of the codebase, as a cohort of sorts.

I think that would be a great idea.  Separating the work across our
respective forces would be beneficial to the project.  However, that
would require someone that can organize this workgroup and give it some
inertia and a direction on where to start.

-- 
Olivier Dion
Polymtl

Re: Maintenance and future of Guile

[Mike Gran]

On Sun, Dec 19, 2021 at 04:11:05PM -0500, Olivier Dion via Developers list for Guile, the GNU extensibility library wrote:
> On Mon, 20 Dec 2021, Blake Shaw <blake@nonconstructivism.com> wrote:
> > In a situation like this, I would recommend that we form a little
> > working group to collectively study the implementation of Guile, and
> > with Ludo's suggestions come up with a roadmap for tackling various
> > areas of the repo/compiler/infrastructure that need work, which we
> > could then divide up among ourselves with each of us creating a
> > presentation on our assigned areas, with group hack sessions following
> > each bi-weekly (or whatever) presentation. This way we could
> > distribute the knowledge aquisicition work in a structured fashion
> > while forming a support group for developing a collective
> > understanding of the codebase, as a cohort of sorts.
> 
> I think that would be a great idea.  Separating the work across our
> respective forces would be beneficial to the project.  However, that
> would require someone that can organize this workgroup and give it some
> inertia and a direction on where to start.

For what it is worth, I'm a committer, and I've done a fair amount of
patching of core Guile, sporadically over the years.  So I can at least
help a bit.  I know my way around the C side of things.

But also, historically, my availability varies wildly with family,
health, and day job.

v/r
Mike Gran

Re: Maintenance and future of Guile

[Tim Van den Langenbergh]

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

On 19/12/2021 21:05, Blake Shaw wrote:
> hi folks, from what I'm seeing here it seems like there are quite a few
> of us who are interested in engaging in steady, organized participation
> in Guile's upkeep, but we're unsure whether we're qualified. At the same
> time Ludo needs to find a replacement and Andy is apparently quite busy,
> and some issues in the ecosystem are apparently starting to show their teeth.
> 
> personally I've been programming for about 15 years now but my career
> has been entirely in new media (video, graphics, audio), so while I've
> worked with plenty of lower-level libraries over the years, I didn't
> start to get an itch for compilers until covid happened. I was also
> doing a PhD in philosophy of mathematics at the time (which I've
> postponed indefinitely to prevent being separated from my partner during 
> covid travel craziness) so I definitely think I have the *potential* to
> contribute to a project like Guile, its just a matter of finding the
> time to read some compiler books (which usually are neither short nor easy!).
> 
> It sounds like others are coming from similar-ish places: you feel
> confident in your abilities to accede to the challenges, but lack the
> background that would enable you to take the initiative. So what are we
> TODO?
> 
> In a situation like this, I would recommend that we form a little
> working group to collectively study the implementation of Guile, and
> with Ludo's suggestions come up with a roadmap for tackling various areas
> of the repo/compiler/infrastructure that need work, which we could then
> divide up among ourselves with each of us creating a presentation on our
> assigned areas, with group hack sessions following each bi-weekly (or
> whatever) presentation. This way we could distribute the knowledge
> aquisicition work in a structured fashion while forming a support group for
> developing a collective understanding of the codebase, as a cohort of
> sorts.  
>  
> wdyt?
> 
> ez,
> blake 
> 

That sounds like a good idea, though I wonder what the best way to organise it would be.

IRC, Mattermost, and Rocket Chat seem like the most obvious options for chat. I don't know what would be best for task management, maybe some out-of-the-box kanban?

Ideas, anyone?

Vale,

-Tim.

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

Re: Maintenance and future of Guile

[Blake Shaw]

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

> If someone is interested, please get in touch with us!
>
> While Andy focuses on major improvements to the compiler and VM with a
> long-term vision, I think it would be great to also have people on the
> maintainer team focusing on more day-to-day operations: incremental
> improvements, bug fixes, etc.  I think we’re lucky that there’ve been a
> number of talented contributors chiming in over the last couple of
> years; let’s take advantage of this, at last!
>

Just want to chime in as a new Guile to say that while I'm still
learning, I'm happy to work on any "chores" if there is guidance on how
to do so. exploring guile has been half the fun so far.

I know CHICKEN has a team of "janitors"; perhaps Guile could benefit
from adopting a similar approach? 

-- 
“In girum imus nocte et consumimur igni”

Re: Maintenance and future of Guile

[Ludovic Courtès]

Hi,

Blake Shaw <blake@nonconstructivism.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> If someone is interested, please get in touch with us!
>>
>> While Andy focuses on major improvements to the compiler and VM with a
>> long-term vision, I think it would be great to also have people on the
>> maintainer team focusing on more day-to-day operations: incremental
>> improvements, bug fixes, etc.  I think we’re lucky that there’ve been a
>> number of talented contributors chiming in over the last couple of
>> years; let’s take advantage of this, at last!
>>
>
> Just want to chime in as a new Guile to say that while I'm still
> learning, I'm happy to work on any "chores" if there is guidance on how
> to do so. exploring guile has been half the fun so far.
>
> I know CHICKEN has a team of "janitors"; perhaps Guile could benefit
> from adopting a similar approach? 

Surely.  For my part, while I won’t pretend to do actual work myself, I
can dedicate time to mentor someone willing to step up.

Ludo’.

Maintenance and future of Guile (was: [patch] Add instructions for sending patches)

[Jean Abou Samra]

> Hi,
>
> Dr. Arne Babenhauserheide schreef op za 11-12-2021 om 16:12 [+0100]:
> >/+ (p "To contribute small improvements, please send patches to/
> >/"/
> >/+    (a (@ (href "mailto:guile-devel@gnu.org" 
> <mailto:guile-devel@gnu.org">;))/
> >/"guile-devel@gnu.org")/
> >/+       ".")/
>
> What about contributing _large_ improvements?
> Where should patches for large improvements go?
>
> >/+ (p "For larger changes, please discuss them first in the "/
> >/+ (a (@ (href "https://mail.gnu.org/mailman/listinfo/guile->/
> devel/")) "development mailing list")
>
> What if I tried to discuss them, but nobody answered?
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46258)
> (Not 100% accurate though, because I discussed the interface on IRC a
> bit IIRC? I can't find it in the logs anymore though.)
>
> What if, I then proceed with writing the patches, and nobody responds
> with some points to work on or applies it?
> (https://lists.gnu.org/archive/html/guile-devel/2021-03/msg00026.html)
> (The only response is a +1-style response.)
>
> What if, eight months later, I send a simplified patch series, with
> things made more consistent, and with much more tests, and this time,
> there is exactly one response, with a minor point that is quickly
> addressed
> (https://lists.gnu.org/archive/html/guile-devel/2021-11/msg00019.html),
> but the patches aren't applied?
>
> There have been many commits and two releases since the first patch
> series
> (https://git.savannah.gnu.org/cgit/guile.git/log/?id=653cc0bf953a11432f77ade9c007848e947cc430&qt=range&q=653cc0bf953a11432f77ade9c007848e947cc430..HEAD&ofs=100  <https://git.savannah.gnu.org/cgit/guile.git/log/?id=653cc0bf953a11432f77ade9c007848e947cc430&qt=range&q=653cc0bf953a11432f77ade9c007848e947cc430..HEAD&ofs=100>)
> , without any signs that it will actually ever be applied.
>
> So I guess what I'm trying to say, is that while your patch documenting
> how to contribute seems reasonable to me, it has been very inaccurate
> for me in practice (not your fault!).
>
> Greetings,
> Maxime


I concur with this concern. The patch
https://lists.gnu.org/archive/html/guile-devel/2021-07/msg00000.html
has been proposed five months ago and after
several pings still only saw responses from Maxime.
It comes from a LilyPond developer trying to fix
issues relevant for LilyPond.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16364#19
is a patch allowing to silence the auto-compilation
logging, which is also somewhat relevant to our use
case. It has not seen any reaction.

I see a number of similar cases on the mailing list.

I understand the cost of reviewing and I know that
nobody is entitled to anything in the free software
world. However, I would like to voice the concern that
Guile's maintenance is not scaling, and the project
cannot attract new contributors if patches do not
make it to the main branch. If the current maintainers
need to drop their activity, it would be nice if
they could share maintainership so that at least
bug fixes can be applied.

(NB: Sending this as myself, _not_ after any sort
of discussion at LilyPond.)

Thank you for your consideration,
Jean Abou Samra

Re: Maintenance and future of Guile

[Ludovic Courtès]

Hello Guilers,

Jean Abou Samra <jean@abou-samra.fr> skribis:

> I see a number of similar cases on the mailing list.
>
> I understand the cost of reviewing and I know that
> nobody is entitled to anything in the free software
> world. However, I would like to voice the concern that
> Guile's maintenance is not scaling, and the project
> cannot attract new contributors if patches do not
> make it to the main branch. If the current maintainers
> need to drop their activity, it would be nice if
> they could share maintainership so that at least
> bug fixes can be applied.

I agree and I apologize for the unpleasant situation: it’s clear that I
haven’t been up to the task for several years already.  I’ll discuss
with Andy how I can formally leave the seat to someone with more energy,
whom I’ll be happy to help learn practices and conventions.

If someone is interested, please get in touch with us!

While Andy focuses on major improvements to the compiler and VM with a
long-term vision, I think it would be great to also have people on the
maintainer team focusing on more day-to-day operations: incremental
improvements, bug fixes, etc.  I think we’re lucky that there’ve been a
number of talented contributors chiming in over the last couple of
years; let’s take advantage of this, at last!

Thanks,
Ludo’.

Re: Maintenance and future of Guile

[Taylan Kammer]

On 15.12.2021 11:20, Ludovic Courtès wrote:
> 
> While Andy focuses on major improvements to the compiler and VM with a
> long-term vision, I think it would be great to also have people on the
> maintainer team focusing on more day-to-day operations: incremental
> improvements, bug fixes, etc.  I think we’re lucky that there’ve been a
> number of talented contributors chiming in over the last couple of
> years; let’s take advantage of this, at last!
> 

Sounds like a good idea.  Andy obviously does amazing work and I'm sure
I'm not the only one who's grateful for your contributions as well :-)
but having even some small patches for obvious bugfixes sit around for
months is a bit disheartening.

I won't apply because I don't feel like I'd be up to the task on a
technical level (my C skills in particular suck, my knowledge of Guile
internals is also quite limited) and I have way too many unfinished
projects plus a somewhat stressful 40h/week job...

But I would definitely like to contribute some small patches every now
and then if I know I'll get feedback / have them applied.

-- 
Taylan

Re: Maintenance and future of Guile

[Olivier Dion via Developers list for Guile, the GNU extensibility library]

On Thu, 16 Dec 2021, Taylan Kammer <taylan.kammer@gmail.com> wrote:
> On 15.12.2021 11:20, Ludovic Courtès wrote:
> I won't apply because I don't feel like I'd be up to the task on a
> technical level (my C skills in particular suck, my knowledge of Guile
> internals is also quite limited) and I have way too many unfinished
> projects plus a somewhat stressful 40h/week job...
>
> But I would definitely like to contribute some small patches every now
> and then if I know I'll get feedback / have them applied.

I would also like to contribute in some meaningful way.  In what way
someone with none wizard knowledge of Scheme can contribute the most to the
project?

-- 
Olivier Dion
Polymtl

Re: Maintenance and future of Guile

[Artem Chernyak]

I am in the same boat as Taylan and Olivier. My knowledge isn't up to
snuff to be a full fledged maintainer, but I would love to contribute
more.

I'm able to give 5-10 hours per week to whatever tasks we need to keep
things running smoothly.

On Fri, Dec 17, 2021 at 9:19 AM Olivier Dion via Developers list for
Guile, the GNU extensibility library <guile-devel@gnu.org> wrote:
>
> On Thu, 16 Dec 2021, Taylan Kammer <taylan.kammer@gmail.com> wrote:
> > On 15.12.2021 11:20, Ludovic Courtès wrote:
> > I won't apply because I don't feel like I'd be up to the task on a
> > technical level (my C skills in particular suck, my knowledge of Guile
> > internals is also quite limited) and I have way too many unfinished
> > projects plus a somewhat stressful 40h/week job...
> >
> > But I would definitely like to contribute some small patches every now
> > and then if I know I'll get feedback / have them applied.
>
> I would also like to contribute in some meaningful way.  In what way
> someone with none wizard knowledge of Scheme can contribute the most to the
> project?
>
> --
> Olivier Dion
> Polymtl
>

Re: Maintenance and future of Guile

[Ludovic Courtès]

Hi,

Olivier Dion <olivier.dion@polymtl.ca> skribis:

> I would also like to contribute in some meaningful way.  In what way
> someone with none wizard knowledge of Scheme can contribute the most to the
> project?

Triage of bugs and patches is always welcome I guess, and communicating
what needs to be applied/addressed first to whoever can actually commit
it.  That’s one possible way to help.

Thanks,
Ludo’.

Re: Maintenance and future of Guile

[Olivier Dion via Developers list for Guile, the GNU extensibility library]

On Fri, 17 Dec 2021, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi,
>
> Olivier Dion <olivier.dion@polymtl.ca> skribis:
>
>> I would also like to contribute in some meaningful way.  In what way
>> someone with none wizard knowledge of Scheme can contribute the most to the
>> project?
>
> Triage of bugs and patches is always welcome I guess, and communicating
> what needs to be applied/addressed first to whoever can actually commit
> it.  That’s one possible way to help.

Where can this be done?  I know that Guix is using debbugs, but do Guile
does the same or is it all tracked on Savannah?

Also, any way to help on the C side?

-- 
Olivier Dion
Polymtl

Re: Maintenance and future of Guile

[Taylan Kammer]

On 17.12.2021 16:48, Olivier Dion wrote:
> On Fri, 17 Dec 2021, Ludovic Courtès <ludo@gnu.org> wrote:
>> Hi,
>>
>> Olivier Dion <olivier.dion@polymtl.ca> skribis:
>>
>>> I would also like to contribute in some meaningful way.  In what way
>>> someone with none wizard knowledge of Scheme can contribute the most to the
>>> project?
>>
>> Triage of bugs and patches is always welcome I guess, and communicating
>> what needs to be applied/addressed first to whoever can actually commit
>> it.  That’s one possible way to help.
> 
> Where can this be done?  I know that Guix is using debbugs, but do Guile
> does the same or is it all tracked on Savannah?
> 
> Also, any way to help on the C side?
> 

Guile also uses Debbugs:

https://bugs.gnu.org/guile

-- 
Taylan

Re: Maintenance and future of Guile

[Ludovic Courtès]

Hi,

Olivier Dion <olivier.dion@polymtl.ca> skribis:

> On Fri, 17 Dec 2021, Ludovic Courtès <ludo@gnu.org> wrote:
>> Hi,
>>
>> Olivier Dion <olivier.dion@polymtl.ca> skribis:
>>
>>> I would also like to contribute in some meaningful way.  In what way
>>> someone with none wizard knowledge of Scheme can contribute the most to the
>>> project?
>>
>> Triage of bugs and patches is always welcome I guess, and communicating
>> what needs to be applied/addressed first to whoever can actually commit
>> it.  That’s one possible way to help.
>
> Where can this be done?  I know that Guix is using debbugs, but do Guile
> does the same or is it all tracked on Savannah?

It’s happening on debbugs.gnu.org as well.  Debbugs this is easier to
work with via Emacs debbugs.el, which is nice if you already use Emacs
but otherwise unfortunate.

> Also, any way to help on the C side?

There isn’t much happening on the C side.  Maxime Devos submitted
patches adding bindings for openat(2) and friends that are unfortunately
still pending review.

Patches that add POSIX bindings and similar to libguile should in
general be relatively easy to review (though the openat(2) one may be
trickier because it’s a central functionality and we’d rather get the
interface right.)

Thanks,
Ludo’.

Re: Maintenance and future of Guile

[Aleix Conchillo Flaqué]

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

I'm not sure how all this ended up.

But, I would encourage and love for Maxime Devos to be a Guile maintainer.
Always great feedback in Guile and other projects (like Fibers) and I
really feel Guile would benefit a lot from their contributions.

Just a thought.

Aleix

On Tue, Dec 21, 2021 at 6:27 AM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Olivier Dion <olivier.dion@polymtl.ca> skribis:
>
> > On Fri, 17 Dec 2021, Ludovic Courtès <ludo@gnu.org> wrote:
> >> Hi,
> >>
> >> Olivier Dion <olivier.dion@polymtl.ca> skribis:
> >>
> >>> I would also like to contribute in some meaningful way.  In what way
> >>> someone with none wizard knowledge of Scheme can contribute the most
> to the
> >>> project?
> >>
> >> Triage of bugs and patches is always welcome I guess, and communicating
> >> what needs to be applied/addressed first to whoever can actually commit
> >> it.  That’s one possible way to help.
> >
> > Where can this be done?  I know that Guix is using debbugs, but do Guile
> > does the same or is it all tracked on Savannah?
>
> It’s happening on debbugs.gnu.org as well.  Debbugs this is easier to
> work with via Emacs debbugs.el, which is nice if you already use Emacs
> but otherwise unfortunate.
>
> > Also, any way to help on the C side?
>
> There isn’t much happening on the C side.  Maxime Devos submitted
> patches adding bindings for openat(2) and friends that are unfortunately
> still pending review.
>
> Patches that add POSIX bindings and similar to libguile should in
> general be relatively easy to review (though the openat(2) one may be
> trickier because it’s a central functionality and we’d rather get the
> interface right.)
>
> Thanks,
> Ludo’.
>
>

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

Re: Maintenance and future of Guile

[zimoun]

Hi,

On ven., 17 déc. 2021 at 10:48, Olivier Dion via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org> wrote:

> Where can this be done?  I know that Guix is using debbugs, but do Guile
> does the same or is it all tracked on Savannah?

Just to mention that Mumi (a web frontend of Debbugs) is serving all GNU
bugs or patches managed by Debbugs.  For one example about Guile,

    <http://issues.guix.gnu.org/issue/56665>

Therefore, it could be a drop-in replacement of
<http://bugs.gnu.org/56665> (the venerable Debbugs frontend).


Well, Mumi is written in Guile, so maybe the Guile community could help
to improve the situation for the whole GNU community using the GNU
instance of Debbugs.

	https://git.elephly.net/software/mumi.git


Cheers,
simon

Re: Maintenance and future of Guile

[Blake Shaw]

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

Considering this conversation is coming back, I'd mention that I'd be happy
to become a Guile "janitor" (as discussed earlier) with some guidance, as
I've only been using Guile for a year and still learning the internals, but
have some patch series fixing some old bugs I've found.

I could also help with efforts like getting Guile's bug tracker to use
Mumi, and cleaning up various cobwebs -- noble & necessary custodial work :)

On Sat, Aug 20, 2022, 01:46 zimoun <zimon.toutoune@gmail.com> wrote:

> Hi,
>
> On ven., 17 déc. 2021 at 10:48, Olivier Dion via "Developers list for
> Guile, the GNU extensibility library" <guile-devel@gnu.org> wrote:
>
> > Where can this be done?  I know that Guix is using debbugs, but do Guile
> > does the same or is it all tracked on Savannah?
>
> Just to mention that Mumi (a web frontend of Debbugs) is serving all GNU
> bugs or patches managed by Debbugs.  For one example about Guile,
>
>     <http://issues.guix.gnu.org/issue/56665>
>
> Therefore, it could be a drop-in replacement of
> <http://bugs.gnu.org/56665> (the venerable Debbugs frontend).
>
>
> Well, Mumi is written in Guile, so maybe the Guile community could help
> to improve the situation for the whole GNU community using the GNU
> instance of Debbugs.
>
>         https://git.elephly.net/software/mumi.git
>
>
> Cheers,
> simon
>
>

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