Hi,
On Tue, 11 Mar 2025 at 13:12, Suhail Singh wrote:
> Are the relevent portions of your .emacs or init.el accessible
> somewhere?
https://gitlab.com/zimoun/my-conf
Cheers,
simon
On Sun, 9 Mar 2025 17:26:07 -0400
Leo Famulari wrote:
> And only using GPL2 is part of that. It's a pragmatic choice in favor
> of the goals of Linux's leadership team, which are different from
> GNU's goals. Of course, Linux couldn't feasibly change to GPL3
> because their copyright licensing mo
On Tue, 11 Mar 2025 02:32:42 +0100
Denis 'GNUtoo' Carikli wrote:
> Another issue is that we'd probably need to tell contributors not to
> expect reviews within the forge. It could be told inside the Guix
> manual. And at the end of the day, if contributors don't understand
> that, it will probably
On Mon, 10 Mar 2025 11:37:29 +0100
Simon Tournier wrote:
> Yes, this can be fixed with tooling. But that’s the wrong frame for
> an answer, IMHO. The question is: who commits in maintaining such
> tools?
This is a good point. One possibility is that someone write tools and
that they are collecti
On Fri, 7 Mar 2025 15:02:57 -0500
Leo Famulari wrote:
> One thing about how Linux solved these issues, is that it Linux became
> commercially valuable to the point where they pay people to maintain
> the code, which includes reviewing contributions.
I used Linux as an example because I know it wa
On Mon, Mar 10, 2025 at 11:32:37PM +0100, Denis 'GNUtoo' Carikli wrote:
> It is possible to require to license things under GPLv2-or-later for
> instance, so technically it is not a big issue. VLC also managed to do
> license changes, as well as Openstreetmap.
It's possible to do GPL2 or later, an
Hi Simon,
Simon Tournier writes:
> Yeah, I’m happy with my setup and I shared [3] several times how Emacs +
> Notmuch + Org-mode is really nice for me. And I also engaged [4] how
> public-inbox can help.
Are the relevent portions of your .emacs or init.el accessible
somewhere?
--
Suhail
On Mon, 10 Mar 2025 11:37:29 +0100
Simon Tournier wrote:
> Hi Denis, all,
Hi,
> That’s said, we must recognize that sending patches by emails is not
> smooth at all.
Indeed. The configuration (smtp settings, or learning how to import
patches in mail clients before sending them, etc) is probably
On Fri, 7 Mar 2025 15:02:57 -0500
Leo Famulari wrote:
> And still you can find endless complaints about their onerous
> contribution workflow
If more people can send patches, it is indeed very good, but the point
of these workflow and tools is also to prioritize the efficient of the
maintainers o
Hi Denis, all,
I agree with some points you list here. For instance, using Codeberg,
somehow we do not apply the dogfooding principle of “user-autonomy”; as
I pointed [1] very early in the discussion. :-)
Moreover, it also raises practical considerations as the backup [2] of
all the discussions
Hi Leo,
Leo Famulari writes:
> On Sun, Mar 09, 2025 at 01:55:46PM +0900, Maxim Cournoyer wrote:
>> Which many concessions to pragmatism are you referring to? The only one
>> I can think of is allowing devices to load their non-free firmwares, but
>> I'm not even sure this was a concession, more
On Sun, Mar 09, 2025 at 01:55:46PM +0900, Maxim Cournoyer wrote:
> Which many concessions to pragmatism are you referring to? The only one
> I can think of is allowing devices to load their non-free firmwares, but
> I'm not even sure this was a concession, more of a 'I don't care what
> code runs
Hi Leo,
Leo Famulari writes:
> On Fri, Mar 07, 2025 at 04:39:34PM +0100, Denis 'GNUtoo' Carikli wrote:
>> If we look at big projects like Linux, they have faced a similar issue
>> in the past and as I understand they solved it by using more adapted
>> tools and processes and they even ended up m
On Fri, Mar 07, 2025 at 04:39:34PM +0100, Denis 'GNUtoo' Carikli wrote:
> If we look at big projects like Linux, they have faced a similar issue
> in the past and as I understand they solved it by using more adapted
> tools and processes and they even ended up making their own software
> tools (git
14 matches
Mail list logo
