ping: Fixes for guile.m4

ping: Fixes for guile.m4

[Alex Sassmannshausen]

Hello,

In December Aleix proposed the following patch to address an issue in
guile.m4 whereby guile programs using the autotools infrastructure would
not find guile and other tools on distributions such as Ubuntu:

http://lists.gnu.org/archive/html/guile-devel/2018-12/msg00002.htm

Guile-Hall, which aims to be a newbie friendly way to create new, and
manage existing guile projects, is also affected by this issue.

What's the status at this point?  Is there anything that needs to happen
before this patch can be merged into Guile?

Best wishes,

Alex

Re: ping: Fixes for guile.m4

[Mike Gran]

On Mon, Jan 21, 2019 at 09:25:17AM +0000, Alex Sassmannshausen wrote:
> Hello,
> 
> In December Aleix proposed the following patch to address an issue in
> guile.m4 whereby guile programs using the autotools infrastructure would
> not find guile and other tools on distributions such as Ubuntu:
> 
> http://lists.gnu.org/archive/html/guile-devel/2018-12/msg00002.htm

+1 on getting this incorporated.  I tested the patch and it worked
for me.

> 
> Guile-Hall, which aims to be a newbie friendly way to create new, and
> manage existing guile projects, is also affected by this issue.
> 
> What's the status at this point?  Is there anything that needs to happen
> before this patch can be merged into Guile?
> 
> Best wishes,
> 
> Alex
> 

It isn't so easy to get one-off patches noticed right now, as far
as I can tell.  Sometimes, you have better luck by putting them
in the bug-tracker, and then Mark might notice them.

-Mike

Re: ping: Fixes for guile.m4

[alex sassmannshausen]

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

Hi Mike,

Thanks for taking the time to test, and for the background info. I hadn't
considered the bug tracker!

I'll see if we can get it in there :)

Cheers,

Alex


On Mon, 21 Jan 2019, 14:42 Mike Gran <spk121@yahoo.com wrote:

> On Mon, Jan 21, 2019 at 09:25:17AM +0000, Alex Sassmannshausen wrote:
> > Hello,
> >
> > In December Aleix proposed the following patch to address an issue in
> > guile.m4 whereby guile programs using the autotools infrastructure would
> > not find guile and other tools on distributions such as Ubuntu:
> >
> > http://lists.gnu.org/archive/html/guile-devel/2018-12/msg00002.htm
>
> +1 on getting this incorporated.  I tested the patch and it worked
> for me.
>
> >
> > Guile-Hall, which aims to be a newbie friendly way to create new, and
> > manage existing guile projects, is also affected by this issue.
> >
> > What's the status at this point?  Is there anything that needs to happen
> > before this patch can be merged into Guile?
> >
> > Best wishes,
> >
> > Alex
> >
>
> It isn't so easy to get one-off patches noticed right now, as far
> as I can tell.  Sometimes, you have better luck by putting them
> in the bug-tracker, and then Mark might notice them.
>
> -Mike
>

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

moving to gitlab? (was: Re: ping: Fixes for guile.m4)

[Aleix Conchillo Flaqué]

On Mon, Jan 21, 2019 at 6:59 AM Mike Gran <spk121@yahoo.com> wrote:

> It isn't so easy to get one-off patches noticed right now, as far
> as I can tell.  Sometimes, you have better luck by putting them
> in the bug-tracker, and then Mark might notice them.
>

Any chance or interest in moving to gitlab? My apologies if this has
been discussed already. Not that I ever contribute anything directly
to Guile (2 patches in 6 years?), but it feels like it would be an
improvement in terms of communication, sending patches, etc. May be it
would even encourage more developers to contribute? Sending patches
over a mailing list shouldn't be a thing anymore. Again, my apologies.

Aleix

Re: moving to gitlab?

[Greg Troxel]

Aleix Conchillo Flaqué <aconchillo@gmail.com> writes:

> Any chance or interest in moving to gitlab? My apologies if this has
> been discussed already. Not that I ever contribute anything directly
> to Guile (2 patches in 6 years?), but it feels like it would be an
> improvement in terms of communication, sending patches, etc. May be it
> would even encourage more developers to contribute? Sending patches
> over a mailing list shouldn't be a thing anymore. Again, my apologies.

I can't speak for the coalition, but generally there is a notion that
FSF projects are hosted on infrastructure operated by a charitable
non-profit that has the advancement of Free Software as the goal.

Also, history shows that the place people move to because of concerns
about $PREVIOSU_PLACE will follow suit eventually...

If your point is that the self-hosted infrastructure should have some
way for random poeple to provide in-tool changes, that sounds sensible.

Re: moving to gitlab?

[Nala Ginrut]

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

First, I hope Guile can use gitlab.
However, IIRC, RMS has some comments on this, the hosting service must be
free, and it shouldn't allow to fork, but branch-based. This is reasonable
to protect project, but RMS speaks as a skilled hacker, I have to say it's
very good policy in a professional engineers team to be branch-based.
But nowadays, people hope FOSS project be easier to contribute, fork is
easier for them.
I accept patches on Gitlab for GNU Artanis.

BTW, that's the main reason I write GNU Artanis, since I'd like to provide
a new Savannah to provide modern services and abey FSF ethic. Although it's
in a very slow stepping toward to final target...

Greg Troxel <gdt@lexort.com> 于 2019年1月23日周三 09:32写道：

> Aleix Conchillo Flaqué <aconchillo@gmail.com> writes:
>
> > Any chance or interest in moving to gitlab? My apologies if this has
> > been discussed already. Not that I ever contribute anything directly
> > to Guile (2 patches in 6 years?), but it feels like it would be an
> > improvement in terms of communication, sending patches, etc. May be it
> > would even encourage more developers to contribute? Sending patches
> > over a mailing list shouldn't be a thing anymore. Again, my apologies.
>
> I can't speak for the coalition, but generally there is a notion that
> FSF projects are hosted on infrastructure operated by a charitable
> non-profit that has the advancement of Free Software as the goal.
>
> Also, history shows that the place people move to because of concerns
> about $PREVIOSU_PLACE will follow suit eventually...
>
> If your point is that the self-hosted infrastructure should have some
> way for random poeple to provide in-tool changes, that sounds sensible.
>
>

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

Re: moving to gitlab?

[Aleix Conchillo Flaqué]

On Tue, Jan 22, 2019 at 5:30 PM Greg Troxel <gdt@lexort.com> wrote:
>
> Aleix Conchillo Flaqué <aconchillo@gmail.com> writes:
>
> > Any chance or interest in moving to gitlab? My apologies if this has
> > been discussed already. Not that I ever contribute anything directly
> > to Guile (2 patches in 6 years?), but it feels like it would be an
> > improvement in terms of communication, sending patches, etc. May be it
> > would even encourage more developers to contribute? Sending patches
> > over a mailing list shouldn't be a thing anymore. Again, my apologies.
>
> I can't speak for the coalition, but generally there is a notion that
> FSF projects are hosted on infrastructure operated by a charitable
> non-profit that has the advancement of Free Software as the goal.
>
> Also, history shows that the place people move to because of concerns
> about $PREVIOSU_PLACE will follow suit eventually...
>
> If your point is that the self-hosted infrastructure should have some
> way for random poeple to provide in-tool changes, that sounds sensible.

I realize I might have opened a can of worms, but yes, mainly that
would be the main motivation. Making it more easy for people to
contribute. Nowadays people are used to these kind of tools and, in my
experience, they are really useful.

Thanks,

Aleix

Re: moving to gitlab?

[Mike Gran]

On Tue, Jan 22, 2019 at 08:18:25PM -0800, Aleix Conchillo Flaqu� wrote:
> On Tue, Jan 22, 2019 at 5:30 PM Greg Troxel <gdt@lexort.com> wrote:
> >
> > Aleix Conchillo Flaqu� <aconchillo@gmail.com> writes:
> >
> > > Any chance or interest in moving to gitlab? My apologies if this has
> > > been discussed already. Not that I ever contribute anything directly
> > > to Guile (2 patches in 6 years?), but it feels like it would be an
> > > improvement in terms of communication, sending patches, etc. May be it
> > > would even encourage more developers to contribute? Sending patches
> > > over a mailing list shouldn't be a thing anymore. Again, my apologies.
> >

...

> I realize I might have opened a can of worms, but yes, mainly that
> would be the main motivation. Making it more easy for people to
> contribute. Nowadays people are used to these kind of tools and, in my
> experience, they are really useful.

I don't think that would help. The challenge is that bug-fixing and
patch review isn't really where the maintainers' effort is right now.
Guix and Guile 3 are the major efforts.  We don't need to make it
easier to submit patches.  We need to make it easier to incorporate
patches.

Some projects (like Pixman) have a rule that if a patch receives no
opposition after a few weeks and a couple of pings, you are free to
push it.  I wonder if that would work here? Or would it be too
chaotic?

My two cents,

Mike Gran

Re: moving to gitlab?

[Amin Bandali]

On 2019-01-23  6:51 AM, Mike Gran wrote:
[...]
> I don't think that would help. The challenge is that bug-fixing and
> patch review isn't really where the maintainers' effort is right now.
> Guix and Guile 3 are the major efforts.  We don't need to make it
> easier to submit patches.  We need to make it easier to incorporate
> patches.
>

+1; I get this impression as well.

>
> Some projects (like Pixman) have a rule that if a patch receives no
> opposition after a few weeks and a couple of pings, you are free to
> push it.  I wonder if that would work here? Or would it be too
> chaotic?
>

I have an inkling that that could indeed end up being a bit chaotic.
Though, if there are a few regular contributors that are really in sync
and in tune with each other the likelihood of that may decrease.


To go off on a tangent, I’d like to second Brett’s suggestion of looking
into Drew DeVault’s sr.ht [1] instead of GitLab.  As someone who’s used
both the various “modern” JS-based in-browser tools and the good old
email-driven workflows, I understand it may be a matter of preference,
but I’d personally *hate* to get stuck having to use a slow and sluggish
web app that uses the latest and shiniest trendy crappy JS framework of
the day that eats up the entire 8GBs of memory on my computer.  I much
rather the comfort of my Gnus + (Ma)git-based workflows in GNU Emacs.

What’s great about sr.ht is that it treats email as first class citizen,
but also provides small and bloat-free web interfaces which are as
JS-free as possible that expose some of the features to the users who
prefer using their browsers.

Though I think sr.ht still has ways to go to be a suitable replacement
for Savannah, there’s already a lot work put into it and it’s looking
really promising so far.  I wonder if it would be a good idea at some
point in the future to suggest it to the FSF sysadmins as a possible
replacement/complement for Savannah.  Regardless, it’d be great to have
it evaluated [2] according to the GNU ethical repository criteria [3].

Footnotes:
[1]  https://sr.ht

[2]  https://www.gnu.org/software/repo-criteria-evaluation.html

[3]  https://www.gnu.org/software/repo-criteria.en.html