What I proposed is in terms of the scope of a single package. The
teams cover much larger and broader scope, like Gnome or Python.
On Mon, Feb 5, 2024 at 12:50 PM Clément Lassieur wrote:
> On Mon, Feb 05 2024, Andy Tai wrote:
> > Thus this creates kind of pseudo package maintainer in Guix, reduci
We had a very interesting discussion about the Hurd. I ran the Hurd
before, but now I am going down the rabbit hole of reading device
drivers and such. It is very interesting.
I envisage a 'Cloud Hurd' that have minimal hardware demands and a
Guix system definition. Running a Guile webserver, fo
Hi Steve,
It would also be nice to write a BLOG about what was discussed at Guix
days and FOSDEM. That way we get a historical record. If you take the
lead we can collect the notes that were made and write a concise
overview of each discussion. I am sure people are happy to help. That
an idea?
Pj
Hello Guix,
In order to test the latest installer, I went to the "latest download"
page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
and ended up on an error page [2]:
"""
{"error":"Could not find the requested build product."}
"""
[1]: https://guix.gnu.org/en/download/late
Hello,
I am in the process of moving my production machine
to a pure Guix setup, and feeling some pain which I
feel is somewhat unnecessary.
There are two extremes supported by the Guix system
in configuring services: either a native application
configuration file is given and used verbatim
Hi Guix,
Tomas Volf <~@wolfsden.cz> writes:
> Or, to put it in a different way: The problem is not that too few patches get
> merged. The problem is that too few patches get reviewed.
I'd say that both things stem from the same premise, a disproportion of
available resources to the work that
Hi Hartmut,
Apologies, my reply-to went a bit mad and I sent you empty emails :-(
You said:
> The current mail-based workflow is too complicated for new and
> occasional committers. This is the main reason I gave up reviewing patches.
>
In the case of *reviewing patches* can you give some exam
Hi Oleg (and the go-team),
As I have spent some time with the go-build-system, I have a couple of
extra suggestions/ideas. Obviously, as the person suggesting these
changes, I would be more than happy to help implement them. This will
unfortunately be a rather lengthy and very information-dense em
On 05/02/2024 15:57, Clément Lassieur wrote:
Hello,
On Mon, Feb 05 2024, Steve George wrote:
Hi,
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?
Patch flow is a pipeline, to change it we co
Hi Leo,
On 05/02/2024 14:07, Leo Famulari wrote:
On Mon, Feb 5, 2024, at 04: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?
Patch flow is a pipeline, to change it we c
Hartmut, thank you for elaborating.
Hartmut Goebel writes:
> * when has this issue/patch been worked on last - is somebody
>currently working on it
> * what issue/patches I started to review?
> ...
> * Even when using the debbugs interface in emacs
> ...
> o It does not tell what iss
On Mon, Feb 05 2024, Andy Tai wrote:
> Hi, this is a sugestion on guix patches:
>
> Other GNU/Linux distributions often have fixed maintainers (or
> packagers) for specific packages.
> While that model may not apply directly to the Guix project as anyone
> can send in patches for anything in the g
Am 05.02.24 um 19:44 schrieb Suhail:
Could you please share a reference where the key difficulties you
encountered wrt the "current mail-based workflow" are summarized. Is
the difficulty regd. checking out the code at the right commit and
installing the patches, or something else?
It's not onl
Hi Suhail,
On Mon, Feb 05 2024, suh...@bayesians.ca wrote:
> Felix Lechner via writes:
>
> Is your position that
First off, I'm sorry I write so much today. For a project the size of
Guix, it's not good for one person to belabor a point repeatedly. I am
responding to your request for a clarific
Hi,
I stick to this flow
- pick a package from golang.scm e.g. go-package-a
- identify destination (any of golang-*.scm)
- place go-package-a to e.g. golang-web.scm in alphabetic order
- remove go-package-a from golang.scm
- by using magit find all authors contributing to go-package-a
- place foun
Am 16.11.23 um 15:22 schrieb Ludovic Courtès:
We could distinguish security issues in packages provided by Guix from
security issues in Guix itself.
Maybe its also a good idea to add a security.txt to the website?
https://en.wikipedia.org/wiki/Security.txt "is meant to allow security
research
Hi, this is a sugestion on guix patches:
Other GNU/Linux distributions often have fixed maintainers (or
packagers) for specific packages.
While that model may not apply directly to the Guix project as anyone
can send in patches for anything in the git repo, maybe one thing the
Guix project can do
Felix Lechner via writes:
> Another is that committers should commit what they think is right
> rather than ask for revised patches.
I could be mistaken, but I believe this does happen today at least some
of the time. Is your position that
1. this never happens today and thus, should happen so
On Mon, Feb 05 2024, Felix Lechner via wrote:
> On Mon, Feb 05 2024, Clément Lassieur wrote:
>
>> On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU
>> System distribution." wrote:
>>
>> I see no evidence here. And I'm unsure which plan you are talking
>> about (the plan
Hartmut Goebel writes:
> This list is missing one point - which has been discussed several
> times already without any result:
>
> The current mail-based workflow is too complicated for new and
> occasional committers.
Could you please share a reference where the key difficulties you
encountered
Hi,
Okay that's a better plan :)
Let's use Occam's razor for now. We have few common groups,
the task is to drop use-module (gnu packages golang) for each
of them by sorting packages into recently introduced modules.
Right, put the dependencies in of golang-web in golang-web (etc.) as
much as
On Mon, Feb 05 2024, Clément Lassieur wrote:
> On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU
> System distribution." wrote:
>
> I see no evidence here. And I'm unsure which plan you are talking
> about (the plan?).
Two people can look at the same thing and reach di
Am 05.02.24 um 10:39 schrieb Steve George:
Hinders
This list is missing one point - which has been discussed several times
already without any result:
The current mail-based workflow is too complicated for new and
occasional committers. This is the main reason I gave up reviewing patches.
On Mon, Feb 05 2024, Suhail wrote:
> Tomas Volf <~@wolfsden.cz> writes:
>
>> In ideal world, there would always be *some* reaction from the
>> project, even if that reaction would be "we do not want this change".
>
> Agreed. A reduction in the time between a patch (or patch revision)
> submission
Hi Maxim and v...@mail-on.us,
I'm including 43...@debbugs.gnu.org to keep track of the discussion on
this feature request (Add the ability to install GuixSD offline)
Maxim Cournoyer writes:
> v...@mail-on.us writes:
>
>> x86 x64 gnu guix system 1.4.0 iso requires internet connection in order to
On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU
System distribution." wrote:
> Hi Clément,
>
> On Mon, Feb 05 2024, Clément Lassieur wrote:
>
>> I don't think reviewers have to be committers.
>
> How much more evidence does the project need to see in order to realize
>
Le lundi 05 février 2024 à 17:21 +, Suhail a écrit :
> > Even if it would be just an auto-close (for the "contributor can't
> > work effectively..." case).
>
> Are there current instances of "contributor can't work effectively"?
> If
> not, I propose that decisions concerning those situations
Tomas Volf <~@wolfsden.cz> writes:
> In ideal world, there would always be *some* reaction from the
> project, even if that reaction would be "we do not want this change".
Agreed. A reduction in the time between a patch (or patch revision)
submission and a review/reaction would be a positive cha
Hi Clément,
On Mon, Feb 05 2024, Clément Lassieur wrote:
> I don't think reviewers have to be committers.
How much more evidence does the project need to see in order to realize
that the plan is not working?
I'll spare the list a lengthy analysis of the social dynamics but the
delegation of com
Hello,
On Mon, Feb 05 2024, Steve George wrote:
> Hi,
>
> 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?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of comm
On 2024-02-05 09:07:05 -0500, Leo Famulari wrote:
> However, I think the question assumes that all contributions should be
> accepted, and that the entire problem is that we are not accepting them
> efficiently enough. We should not unconsciously accept this assumption.
>
> Guix can reject contri
On Mon, Feb 5, 2024, at 04: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?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of committers
Hello,
Thank you for your research on that, I was not expected to go
far like you did :-)
My short plan was to follow existing naming model which is in
use for python-*.scm, lisp-*.scm, perl-*scm, java-*.scm.
I see that golang would need some extra modules in the future
and comparing with python-
Hello developers,
Ipse dixit: a tag is a tag is a tag.
Sorry to stress on this but AFAIU "git describe" and it's variants is
(mis)used by some (many?) to obtain the last revision number of packages
got from a git tag on a repo, even in few upstream build config/scripts
(patched in Guix); here are
Hi,
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?
Patch flow is a pipeline, to change it we could:
a. Increase the number of committers - more people to do the
work
b. Increase the efficienc
45 matches
Mail list logo
