zimoun writes:
[...]
>> * Over all for me debbugs.el needs a much more "noops"-friendly
>> interface
>
> Well, I think ’public-inbox’ could help. An instance is:
>
> https://yhetil.org/guix-patches/
>
> where using lei, you can filter and receive to your inbox the patches.
> For
Hi Hartmut,
On Mon, 20 Jun 2022 at 14:53, Hartmut Goebel
wrote:
> my system is set up to emacs could send out mails.
Well, if you are already using Emacs, the Emacs front-end is not the
nicest interface but does part of the job. I have this:
--8<---cut
Hi,
here are my reasons for reviewing patches very very rarely-
Basically I share Brian Cully's experiences. I'm using Thunderbird for
mail and my system is set up to emacs could send out mails.
I tried debbugs from time to time and for me it is disgusting:
* too complicated to get to the
>> Also, should we remove old/broken/unused/rarely-used packages from Guix?
>> In the past, I have packaged and contributed very niche packages which
>> probably no one else uses, and sometimes even I don't use anymore. But,
>> these packages continue to stay in Guix and add to the maintenance
> On 15 Jun 2022, at 09:15, Arun Isaac wrote:
>
> I would also like to raise a couple of more controversial suggestions:
>
> Should we restrict the set of packages that will be accepted into Guix?
> Currently, we accept practically any free software package into
> Guix. Should we limit the
Hi Simon,
zimoun writes:
> On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo wrote:
>
>>> It reduces a bit the pressure on the committers, IMHO.
>>
>> It raises a bit the pressure on the maintainers, IMHO :-)
>
> What does it mean “maintainer” here?
Guix maintainers
> Maybe I miss something
Hi,
Arun Isaac skribis:
>> That’s why, I think the project should:
>>
>> 1. change the default branch of “git push” vs the default branch of
>> “guix pull”.
>>
>> 2. add a bit more of checkers on patch submission easing patch
>> review.
>
> I like and support both these ideas. Maybe, they
Hi,
> That’s why, I think the project should:
>
> 1. change the default branch of “git push” vs the default branch of
> “guix pull”.
>
> 2. add a bit more of checkers on patch submission easing patch
> review.
I like and support both these ideas. Maybe, they are even long overdue!
;-)
I
>>> Personally, I think nowadays this purpose is better fulfilled by
>>> good commit messages and git blame. Especially with an editor that makes
>>> it easy to use them to navigate through history (such as Emacs, but
>>> certainly others as well).
>>
>> Because these standards, it is easy to
Hello,
zimoun writes:
> Hi,
>
> On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann
> wrote:
>
>> But I do think it's one more source of “friction” for new contributors,
>> and one more thing for us to require that they get right.
>
> [...]
>
>> There's one in the GNU Coding Standards¹:
>
>
Hi,
On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo wrote:
>> It reduces a bit the pressure on the committers, IMHO.
>
> It raises a bit the pressure on the maintainers, IMHO :-)
What does it mean “maintainer” here?
Maybe I miss something but I do not think the Guix maintainers play a
special
Hi,
On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann
wrote:
> But I do think it's one more source of “friction” for new contributors,
> and one more thing for us to require that they get right.
[...]
> There's one in the GNU Coding Standards¹:
[...]
> Personally, I think nowadays this
Hi Maxime
Maxime Devos writes:
> Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
>> Maxime I have a question for you please: do you really think that in
>> the NixOS community
>
> Going by the Java example, yes, at least for some of the NixOS
> community. I've also seen this
Hi Giovanni,
Rather than any specific criticism of our workflow, my point was that
there are many little things to keep in mind when reviewing patches, and
this makes it demanding. I am pretty happy with Guix's rigorous coding
standards, and am not suggesting we abandon them.
Cheers! :-)
Arun
Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
> Maxime I have a question for you please: do you really think that in
> the NixOS community
Going by the Java example, yes, at least for some of the NixOS
community. I've also seen this interpretation of reproducibility in
Clojure
Hi Maxime and all,
I'm so sorry this discussion is shifting to the actual meaning of
reproducible... especially since Maxime and many of us know it very well
I'm sure 95% of people I know would not understand me if I tell them
that their software should be reproducible, they should study a
Giovanni Biscuolo schreef op zo 12-06-2022 om 11:42 [+0200]:
> > or have packages with bundled dependencies (e.g. vendored jars).
>
> bundling binaries it's (is it?) for sure against the definition of a
> reproducible build, but what about bundling (source) dependencies?
>
> AFAIU not to bundle
Hi Ricardo and all,
following this discussion, it came to my mind a great presentation made
by Prot:
https://protesilaos.com/codelog/2021-12-21-emacsconf2021-freedom/
«How Emacs made me appreciate software freedom»
especially the "You can't be an Emacs tourist" part; I think that
similar
>> - We have strict conventions for commit messages. Our commit message
>> Changelog is a strange dated practice from the time before good
>> version control systems. I can live with it, but not everyone likes
>> it. Let's just say I've heard complaints about it offlist.
>
> AFAIU this is
> Date: Fri, 10 Jun 2022 14:27:44 +0200
> From: Giovanni Biscuolo
> To: Arun Isaac , Guix Devel
>
> Cc: GNU Guix maintainers
> Subject: Re: On commit access, patch review, and remaining healthy
> Message-ID: <87o7z0itz3@xelera.eu>
> Content-Ty
Hi,
Thiago Jung Bauermann skribis:
> The binutils-gdb repo has a Python script to generate a skeleton
> ChangeLog. I don't know how well it would work for Scheme patches:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=contrib/mklog.py;hb=HEAD
I believe the ‘etc/committer.scm’
Hello,
Giovanni Biscuolo writes:
> Arun Isaac writes:
>
>> - We have strict conventions for commit messages. Our commit message
>> Changelog is a strange dated practice from the time before good
>> version control systems. I can live with it, but not everyone likes
>> it. Let's just
Efraim Flashner writes:
[...]
> I'm not using emacs but I've found etc/committer.scm to be quite
> helpful, and I'll often rework parts of my workflow so that I can run
> :!etc/committer.scm from within vim.
uh thanks! I didn't know about committer.scm
please is there some documentation about
Efraim Flashner writes:
> On Fri, Jun 10, 2022 at 02:27:44PM +0200, Giovanni Biscuolo wrote:
[...]
>> I just hope this requirement is refraining people to contribute and to
>> review patches.
>
> I'll reword this as "I just hope this requirement isn't preventing
> people from contributing and
On Fri, Jun 10, 2022 at 02:27:44PM +0200, Giovanni Biscuolo wrote:
> Hi Arun,
>
> thank you for your detailed analysis!
>
<..snip..>
> I just hope this requirement is refraining people to contribute and to
> review patches.
I'll reword this as "I just hope this requirement isn't preventing
Giovanni Biscuolo schreef op vr 10-06-2022 om 14:27 [+0200]:
> > - Our synopses and descriptions are not casually copy-pasted from
> the
> > project website. We try to rewrite and improve on them if
> necessary.
>
> AFAIK similar requirements are "enforced" by all other distributions
They
Hi Arun,
thank you for your detailed analysis!
Arun Isaac writes:
[...]
> I meant that Guix has very high coding/packaging standards in the
> following senses:
>
> - We prefer to not bundle dependencies. Tracking out bundled
> dependencies, git submodules, etc. and figuring out how to
Hi Ludo,
> I can think of two ways to reassure committers:
>
> 1. By having clear reviewer check lists (you’d do that if you tick all
> the boxes, you’re fine);
>
> 2. By improving automation—nothing new here: if there was a tick that
> says “applies without merge conflicts” and
Hi Giovanni,
>> Guix has very high coding standards
>
> Do you think other software distribution do have less high coding
> standards?
I meant that Guix has very high coding/packaging standards in the
following senses:
- We prefer to not bundle dependencies. Tracking out bundled
Efraim Flashner skribis:
> On Tue, Jun 07, 2022 at 05:11:48PM +0200, Ludovic Courtès wrote:
[...]
>> The manual mentions the two web interfaces in addition to Emacs:
>>
>> https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html
>>
>> Do you or would you use them to keep
On Tue, Jun 07, 2022 at 05:11:48PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
>
> Efraim Flashner skribis:
>
> > As someone who has never used debbugs or emacs I find it daunting to try
> > to add it into my workflow. Currently I am subscribed to guix-patches
> > and I dump it into my
Hi Ludo'
Ludovic Courtès writes:
[...]
> OK, understood.
>
> I can think of two ways to reassure committers:
>
> 1. By having clear reviewer check lists (you’d do that if you tick all
> the boxes, you’re fine);
also a description of the review process used by you and other
experienced
Hi Arun,
Arun Isaac writes:
> Tooling aside, at least for me, I think there is an important emotional
> and psychological aspect to patch review. Maybe others share it too. So,
> I'll speak up.
Thanks a lot for your speak up!
> Guix has very high coding standards
Do you think other software
Hi Simon and all,
just a quick note about myself: I'm (still) not contributing with patch
reviews (and in general contributing too little) because in this period
of my "work life" I have little time, but things will hopefully
change...
IMHO the curent tooling is helpful and usable with a little
Hi Efraim,
Efraim Flashner skribis:
> As someone who has never used debbugs or emacs I find it daunting to try
> to add it into my workflow. Currently I am subscribed to guix-patches
> and I dump it into my guix-devel mailing list. I read my mail using mutt
> and will just pipe the patches to
On Fri, Jun 03, 2022 at 09:37:36PM +0200, Ludovic Courtès wrote:
> Hi,
>
> Brian Cully skribis:
>
> > Ludovic Courtès writes:
> >
> >> If you are using Emacs, does debbugs.el have
> >> shortcomings that make it a problem to review patches?
>
> To be clear, the question was directed
Hi,
On Mon, 06 Jun 2022 at 23:43, Ludovic Courtès wrote:
> I can think of two ways to reassure committers:
>
> 1. By having clear reviewer check lists (you’d do that if you tick all
> the boxes, you’re fine);
As pointed earlier by Arun in «Public guix offload server» [1], this
check
Hi Arun,
Arun Isaac skribis:
> Tooling aside, at least for me, I think there is an important emotional
> and psychological aspect to patch review. Maybe others share it too. So,
> I'll speak up.
Thanks a lot for speaking up, your feedback is invaluable.
I did consider that the whole process
Hi all,
Tooling aside, at least for me, I think there is an important emotional
and psychological aspect to patch review. Maybe others share it too. So,
I'll speak up.
Sometimes, I don't review and commit patches because I feel like I am
not qualified to review them, and am afraid of pushing a
Hi Ludo,
> Interesting. Since I already used Gnus before, I didn’t have much to
> learn when I started using debbugs.el.
>
> I know some people here use debbugs.el with other email clients like
> mu4e, so perhaps they can comment? We could add guidance in the
> manual.
Since some time mu4e
Hi,
Pier-Hugues Pellerin skribis:
> As a new-new Guix user, I did find the review process or the time it
> takes really long.
> Maybe I've tackle too complex updates[0], I don't know but I don't
> have a clear path how to push it.
Yeah. :-/
The long delays are mostly due to the lack of
Hi,
Brian Cully skribis:
> Ludovic Courtès writes:
>
>> If you are using Emacs, does debbugs.el have
>> shortcomings that make it a problem to review patches?
To be clear, the question was directed primarily at current committers.
> 1) It’d be nice if ‘M-x debbug-guix’ existed. I
Hi,
On Thursday, June 2nd, 2022 at 15:10, Ludovic Courtès wrote:
> In addition to that, we need to encourage contributors who are not
> committers yet, which obviously means reviewing and applying their
> contributions in a timely fashion. We need to grow prolific
> contributors into leadership
Hello,
As a new-new Guix user, I did find the review process or the time
it takes really long.
Maybe I've tackle too complex updates[0], I don't know but I don't
have a clear path how to push it.
As a dev, I am not super used to the email-patches workflow, I am
more used to the pull-request
Ludovic Courtès writes:
If you are using Emacs, does debbugs.el have
shortcomings that make it a problem to review patches?
I’m new to debbugs in general, and Emacs’ debbugs mode in
particular. However, I have been using it to track the status on
some of my patches, or to just
45 matches
Mail list logo
