> I think a lot of this discussion is stuck on what is better web or
> email. Where it doesn't have to be.
>
> What we instead need to do is acknowledge that some people like the web
> approach.
>
> And accommodate them so we can have guix used by more people. Simple as that
> :D
Exactly.
On 9/22/23 18:14, Imran Iqbal wrote:
On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:
I use protonmail and they don't provide smtp access so I can't do git
send-mail as easy as other people do.
A mail provider not allowing SMTP is a git forge that does not allow git
push.
Hi,
> On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:
>
> > I use protonmail and they don't provide smtp access so I can't do git
> > send-mail as easy as other people do.
>
>
> A mail provider not allowing SMTP is a git forge that does not allow git
> push.
This is a
Imran Iqbal writes:
> Personally I don't think its fair to ask Guix to move away from emails
> because folks are more familiar with using web browsers for everything.
Imran, you bring up good points. I wanted to state that I share this opinion:
Guix should not move away from emails.
I view
On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:
> I use protonmail and they don't provide smtp access so I can't do git
> send-mail as easy as other people do.
A mail provider not allowing SMTP is a git forge that does not allow git
push.
> This is not Guix's fault, but it's a
Hi Simon,
On Mon, Sep 18 2023, Simon Tournier wrote:
>
> To be clear, I dismiss only these two sentences:
Having read your message from earlier today [1] in which I think you
questioned the continued utility of this thread ("could we stop this
useless and unproductive flamewar?") it seems fair
Am Montag, dem 18.09.2023 um 20:39 +0300 schrieb MSavoritias:
>
> On 9/18/23 20:13, Simon Tournier wrote:
> > On Mon, 18 Sept 2023 at 18:35, MSavoritias
> > wrote:
> >
> > > I was talking from my experience. If you don't share it that is
> > > fine.
> > Share what? Your experience? How can I?
engage potentially fruitful discussions. Maybe, that's what you
wanted to express?
Anyway. That's how I view the things from my perspective.
It is my last email in this thread too.
Cheers,
simon
1: Re: How can we decrease the cognitive overhead for contributors?
MSavoritias
Sun, 17 Sep 2023 19
On 9/18/23 20:13, Simon Tournier wrote:
On Mon, 18 Sept 2023 at 18:35, MSavoritias wrote:
I was talking from my experience. If you don't share it that is fine.
Share what? Your experience? How can I? Instead, I share facts
backed by numbers.
It is fine to share how you perceive,
On Mon, 18 Sept 2023 at 18:35, MSavoritias wrote:
> I was talking from my experience. If you don't share it that is fine.
Share what? Your experience? How can I? Instead, I share facts
backed by numbers.
It is fine to share how you perceive, encouraged even! It is not fine
to make bold
On 9/14/23 11:24, Ricardo Wurmus wrote:
Fannys writes:
But again, even if this is a great option for you, it might be a really bad
option for some other people. Everybody does not have the time to spend
learning emacs, or other specific tool. It's ok if the workflow suggests that
but it's
to
prove that email is better or something. Personally i don't care what is
better.
What i care is that some people prefer web-based so we should
accommodate them :) plain and simple.
MSavoritias
Cheers,
simon
1: Re: How can we decrease the cognitive overhead for contributors?
Simon Tour
Hi,
On Sun, 17 Sep 2023 at 14:29, MSavoritias wrote:
> The reason I have come to guix is because it strives to actually make it
> easier for people to change things. with guix shell and such. So making
> it easier for people to contribute is absolutely a part of it. Im not
> saying we should
4]. In summary,
“email vs. web-forge” is a fake-problem, IMHO. Last, the talk [5] by
Enrico Zini appears to me much more fruitful. The question is about
sustain the community. And this sustainability does not clearly depend
on any tool.
Cheers,
simon
1: Re: How can we decrease the cogni
Am Sonntag, dem 17.09.2023 um 19:20 +0300 schrieb MSavoritias:
> Personally free software means that there shouldn't even be a
> separation of Dev and user. But that's another topic.
I mean, the pull request model has this separation baked into it. To
create a pull request, you must have an
On 9/10/23 01:20, Liliana Marie Prikler wrote:
Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus:
Liliana Marie Prikler writes:
Must we force a single workflow on everyone, even if our track
record in reviewing and merging doesn’t clearly show that our way
is superior?
On 9/8/23 21:50, Liliana Marie Prikler wrote:
Hi,
Am Freitag, dem 08.09.2023 um 16:44 +0200 schrieb Ricardo Wurmus:
I often have to review Github Pull Requests, and I don’t go commit by
commit by go through the diff and annotate the changes. I *read* the
commits to get a sense for how the
On 9/12/23 17:51, Maxim Cournoyer wrote:
Hi,
Csepp writes:
Giovanni Biscuolo writes:
[[PGP Signed Part:Undecided]]
Hello Csepp,
Csepp writes:
[...]
I don't think repeating that no forge sucks less advances the
conversation towards any solution other than keeping the status quo,
On 9/13/23 18:42, Maxim Cournoyer wrote:
Hi Fannys,
Fannys writes:
Ekaitz Zarraga writes:
This is what I mean when I say many times emacs is kind of mandatory,
and
this thread is kind of a demonstration of what I meant because the main
discussion evolved to: you can use this or that in
On 9/7/23 23:38, Katherine Cox-Buday wrote:
On 9/5/23 2:43 PM, Liliana Marie Prikler wrote:
Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
Liliana Marie Prikler writes:
Uhm, we have snippets?
Well, those are exclusive to Emacs :) And without regard to /that/
issue, I do think
On 9/6/23 23:10, Wojtek Kosior via Development of GNU Guix and the GNU
System distribution. wrote:
Hello,
I wanted to add to this thread my 2 cents. As a person who has recently
(last months) made the first attempts at contributing.
To me, registrations and reliance on JS had always been an
Hi,
On Thu, 14 Sep 2023 at 23:19, Sarthak Shah wrote:
> I believe that it should not be very hard to create a user interface (web,
> ncurses or GUI) that searches for a package's location (the package record
> has a field that accommodates this) and then displays it, which the user
> can then
I think that quite a few Guix users end up not committing to Guix because
of how daunting and strange the process seems.
In particular, having an alternate, easy-to-use interface for updating
package definitions specifically could be very useful.
The greatest strength of Guix is that it can be
Fannys writes:
>> But again, even if this is a great option for you, it might be a really bad
>> option for some other people. Everybody does not have the time to spend
>> learning emacs, or other specific tool. It's ok if the workflow suggests that
>> but it's not great if we have no other
MSavoritias writes:
> Simon Tournier writes:
>
>> Hi,
>>
>> On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote:
>>
>>> Do you know if there are any plans to write a scheme bug/patching
>>> system? Because looking a bit into it, it doesn't seem like its that
>>> actively developed so maybe we
Hi,
On Wednesday, September 13th, 2023 at 3:42 PM, Maxim Cournoyer
wrote:
>
> There's no lock-in. You can use any tool you want. Most people hacking
> on Guix do so with Emacs and Geiser because these are currently the best
> tools (that I know of) to do the job; these are the tools many of
Hi Fannys,
Fannys writes:
> Ekaitz Zarraga writes:
>
>>> > This is what I mean when I say many times emacs is kind of mandatory,
>>> > and
>>> > this thread is kind of a demonstration of what I meant because the main
>>> > discussion evolved to: you can use this or that in emacs to ease the
mprovements
> that I am necessary following. However, if I see the subject,
>
> guix: toml: Add TOML parser.
>
> then I open the message and read it.
>
> Therefore, I do not see any “good” solution for this point #22. One
> idea would be to have a kind of proxy. We wo
I dont think we need to compare things here. Of course we should be able
to make lives easier for reviewers and contributors. There is no need
here to compare them. Remember that making lives easier for contributors
will make lives easier for reviewers too after all :) Because more
correct
Simon Tournier writes:
> Hi,
>
> On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote:
>
>> Do you know if there are any plans to write a scheme bug/patching
>> system? Because looking a bit into it, it doesn't seem like its that
>> actively developed so maybe we would be better served by one in
Ekaitz Zarraga writes:
>> > This is what I mean when I say many times emacs is kind of mandatory,
>> > and
>> > this thread is kind of a demonstration of what I meant because the main
>> > discussion evolved to: you can use this or that in emacs to ease the
>> > dev
>> > experience.
>>
>>
>>
Ekaitz Zarraga writes:
>> > This is what I mean when I say many times emacs is kind of mandatory,
>> > and
>> > this thread is kind of a demonstration of what I meant because the main
>> > discussion evolved to: you can use this or that in emacs to ease the
>> > dev
>> > experience.
>>
>>
>>
Re,
On Wed, 13 Sep 2023 at 09:57, Simon Tournier wrote:
> Somehow, the line is drawn using a two-axis plot of “easy vs boring”
> when instead we should draw a two-axis plot of “complexity vs capture
> the values”.
I meant, the thread is considering a one-axis plot using a subjective
parameter
Hi Katherine,
On Tue, 12 Sep 2023 at 10:05, Katherine Cox-Buday
wrote:
> And these are subjective statements, which are bad to rest decisions on.
> I have the opinion that this style of commit message is difficult and
> doesn't have a lot of value; others think it's easy and find a lot of
>
is branch of the looooong thread starts with:
Re: How can we decrease the cognitive overhead for contributors?
Attila Lendvai
Fri, 25 Aug 2023 08:07:53 +
id:JRUs8LVm3AtAh0MnHjE5rnhB4sNET0vWTOO2N3w2KfvKoM3CALRNwHTmwJ0Y9Bg3ZDWCs8j-1bMCo9aRiaoac8TAkuXAvrWgSwt_8RcwhQA=@l
On 9/8/23 2:37 PM, Ricardo Wurmus wrote:
Liliana Marie Prikler writes:
Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
I have the same positive view on our faux ChangeLogs commit messages,
though I also would like to have them generated. The benefit is
still there: I
On 9/8/23 5:28 AM, Ricardo Wurmus wrote:
Katherine, I’m very happy you brought this up and continue to respond in
this thread to clarify and steer the discussion into a fruitful
direction. I know I couldn’t do it. I thank you for this work, and I
hope that the project can come up with ways to
On 9/8/23 6:40 AM, Giovanni Biscuolo wrote:
Ricardo,
Ricardo Wurmus writes:
Giovanni,
You are obviously free not to contribute your patches upstream but the
fact that you decided not to because it's "too hard" (my executive
summary about your complaints about Change Log content rules) to
On 9/11/23 6:19 AM, Giovanni Biscuolo wrote:
If you want I can add a little bit of Italian attitide at discussing in
detail tiny variations of the same thing :-O... just joking, eh! ;-)
One of the reasons I love working with people from around the world is
the delight in discovering that
Hi,
Csepp writes:
> Giovanni Biscuolo writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hello Csepp,
>>
>> Csepp writes:
>>
>> [...]
>>
>>> I don't think repeating that no forge sucks less advances the
>>> conversation towards any solution other than keeping the status quo,
>>> which can't
Hi Simon,
Simon Tournier writes:
> Hi Liliana,
>
> On Mon, 11 Sep 2023 at 19:53, Liliana Marie Prikler
> wrote:
>
>> For "patch does not apply", the forge solution is typically to send a
>> notification to the issuer.
>
> No, that does not match my small experience. Because often the issuer
Giovanni Biscuolo writes:
> [[PGP Signed Part:Undecided]]
> Hello Csepp,
>
> Csepp writes:
>
> [...]
>
>> I don't think repeating that no forge sucks less advances the
>> conversation towards any solution other than keeping the status quo,
>> which can't really be called a solution.
>
> Are
Hello Csepp,
Csepp writes:
[...]
> I don't think repeating that no forge sucks less advances the
> conversation towards any solution other than keeping the status quo,
> which can't really be called a solution.
Are we really talking about changing the official Guix forge:
Giovanni Biscuolo writes:
> [[PGP Signed Part:Undecided]]
> Hi Liliana,
>
> Liliana Marie Prikler writes:
>
> [...]
>
>> For example, whenever people say that "forges would improve stuff", my
>> reply is (modulo phrasing) "yes, for the people who are already used to
>> forges".
>
> I just
workflow is far to help us for
having smooth reviews so it’s hard to convince folks already familiar
with other workflows to adopt our. Not saying that these other
workflows are better either.
Cheers,
simon
1: Re: How can we decrease the cognitive overhead for contributors?
Ricardo Wurmus
Fri, 0
Hi Simon,
Am Montag, dem 11.09.2023 um 12:36 +0200 schrieb Simon Tournier:
> Today, the review and commit process have many steps, more or less
> simple, not all sure!, well at the end, we have something complex.
>
> One trivial step is to apply the patch (or series) to your local
> checkout and
Hi Liliana,
Liliana Marie Prikler writes:
[...]
> For example, whenever people say that "forges would improve stuff", my
> reply is (modulo phrasing) "yes, for the people who are already used to
> forges".
I just want to point out that actually Guix _do_have_ a forge. the
software is Savane
Hello,
(I find it difficult to efficiently follow this thread and to keep up to
date with reading it, so please forgive me if someone else already
addressed my considerations)
Simon Tournier writes:
[...]
> « For which contributors do we want to/can we decrease the cognitive
> overhead? », so
Hi Liliana,
On Sun, 10 Sep 2023 at 00:20, Liliana Marie Prikler
wrote:
>> > > Must we force a single workflow on everyone, even if our track
>> > > record in reviewing and merging doesn’t clearly show that our way
>> > > is superior
>> >
>> > Again, define superior.
>>
>> No, I won’t. I
Hi Efraim,
Efraim Flashner writes:
[...]
> On the other hand, if we do manage to automate writing of commit
> messages, it makes one less thing for committers to manually fix before
> pushing the commit.
It would be lovely! It could also be done by a client-side git hook,
provided in the
On Fri, Sep 08, 2023 at 04:20:30PM +0200, Ricardo Wurmus wrote:
>
> Josselin Poiret writes:
>
> > Regarding the “mom argument”, I would disagree and say that this is
> > completely related: interruptions are more costly, you're more likely to
> > have less attention span, and overall you
Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > > Must we force a single workflow on everyone, even if our track
> > > record in reviewing and merging doesn’t clearly show that our way
> > > is superior?
> > Again, define superior.
>
>
Simon Tournier writes:
> On Fri, 08 Sep 2023 at 17:27, Ricardo Wurmus wrote:
>
>> Now, this is no longer a problem for me because I’ve been writing so
>> many commit messages over the years (and because I no longer try to
>> adhere to some poorly specified format), but it *is* a problem for
Liliana Marie Prikler writes:
>> Must we force a single workflow on everyone, even if our track record
>> in reviewing and merging doesn’t clearly show that our way is
>> superior?
> Again, define superior.
No, I won’t. I think it’s obvious that our review process isn’t working
*well*. So
Am Donnerstag, dem 07.09.2023 um 14:39 -0600 schrieb Katherine Cox-
Buday:
> > Somehow, that’s the remark by Liliana [1],
> >
> > Maybe it's time to take a step back and instead of asking
> > “How can we decrease the cognitive overhead for
> > contributors?”, we should
d submitting for example – and it brings no
value at all for the project. Other, as commit message format, also
leads to some friction but it also brings value for the project.
For these latter case, the improvement is not clear for me.
Cheers,
simon
1: Re: How can we decrease the cognit
Hi Katherine,
On Thu, 07 Sep 2023 at 14:39, Katherine Cox-Buday
wrote:
>> Maybe it's time to take a step back and instead of asking “How can
>> we
>> decrease the cognitive overhead for contributors?”, we should
>> perhaps
>> ask “For which contributors do we
Am Freitag, dem 08.09.2023 um 22:24 +0200 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > > On Github, Pull Request branches are like our WIP branches. They
> > > are how we arrive at acceptable changes. Picky people like me
> > > would then go back and write new atomic
Am Freitag, dem 08.09.2023 um 17:39 +0200 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > To be completely honest, mumi recalling everything at 0 precision
> > is my biggest pet peeve at the moment
>
> Can you please make a test case for this and add it to the mumi
> tests? We
Liliana Marie Prikler writes:
> Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
>> I have the same positive view on our faux ChangeLogs commit messages,
>> though I also would like to have them generated. The benefit is
>> still there: I still get to *review* an effective
Liliana Marie Prikler writes:
>> On Github, Pull Request branches are like our WIP branches. They are
>> how we arrive at acceptable changes. Picky people like me would then
>> go back and write new atomic commits for the effective diff, but in
>> my role as a reviewer I usually rebase,
Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
> I have the same positive view on our faux ChangeLogs commit messages,
> though I also would like to have them generated. The benefit is
> still there: I still get to *review* an effective summary of the
> changes before pushing
Hi,
Am Freitag, dem 08.09.2023 um 16:44 +0200 schrieb Ricardo Wurmus:
> I often have to review Github Pull Requests, and I don’t go commit by
> commit by go through the diff and annotate the changes. I *read* the
> commits to get a sense for how the feature evolved and why changes
> were made,
Am Freitag, dem 08.09.2023 um 11:16 +0200 schrieb Giovanni Biscuolo:
> [...]
>
> > > On 2023-09-06, Liliana Marie Prikler wrote:
>
> [...]
>
> > > > It's
> > > >
> > > > * file (variable)[field]{do you need 4
> > > > levels?}
>
> The general form of a ChangeLog Style format for Guix code
Hello Efraim,
Efraim Flashner writes:
> On Fri, Sep 08, 2023 at 11:53:43AM +0200, Giovanni Biscuolo wrote:
> That wasn't my read of it at all.
I don't understand what part of my message is different from your read,
so I cannot comment
> I too have many packages which I haven't upstreamed.
Liliana Marie Prikler writes:
> To be completely honest, mumi recalling everything at 0 precision is my
> biggest pet peeve at the moment
Can you please make a test case for this and add it to the mumi tests?
We have tests for the search feature there.
--
Ricardo
Maxim Cournoyer writes:
> I used to think the same about ChangeLogs style commit messages, but I
> have to admit that it forces some discipline on me by having me review
> my changes in details and write out what I did. It'll sometimes expose
> something that'd be better kept in a separate
Liliana Marie Prikler writes:
>> one fundamental issue with the email based workflow is that its
>> underlying data model simply does not formally encode enough
>> information to be able to implement a slick workflow and frontend.
>> e.g. with a PR based model the obsolete versions of a PR is
Josselin Poiret writes:
> Regarding the “mom argument”, I would disagree and say that this is
> completely related: interruptions are more costly, you're more likely to
> have less attention span, and overall you probably don't want to commit
> to 20 steps just to send a contribution.
That’s
Ricardo,
Ricardo Wurmus writes:
> Giovanni,
>
>> You are obviously free not to contribute your patches upstream but the
>> fact that you decided not to because it's "too hard" (my executive
>> summary about your complaints about Change Log content rules) to write
>> commit messages suitable for
On Fri, Sep 08, 2023 at 11:53:43AM +0200, Giovanni Biscuolo wrote:
> Hello Katherine,
>
> Katherine Cox-Buday writes:
>
> [...]
>
> > By "standard" I mean the GNU Changelog format
> > (https://www.gnu.org/prep/standards/standards.html#Change-Logs). As
> > in: it's expected that commit messages
Giovanni,
> You are obviously free not to contribute your patches upstream but the
> fact that you decided not to because it's "too hard" (my executive
> summary about your complaints about Change Log content rules) to write
> commit messages suitable for contribution it _not_ a Guix
Hi!
Simon Tournier writes:
[...]
> For example, we communicate in English. It appears to me impossible to
> send a contribution without having some basic knowledge of English.
And, believe me or not, for me /that/ is a **significant** cognitive
overhead not just to contribute to
Hello Katherine,
Katherine Cox-Buday writes:
[...]
> By "standard" I mean the GNU Changelog format
> (https://www.gnu.org/prep/standards/standards.html#Change-Logs). As
> in: it's expected that commit messages use this format.
[...]
> In my response I was trying to point out a flaw in your
Hi all!
I think the discussion about ChangeLog Style shows we probably need to:
1. enhance the manual section "22.6 Submitting Patches"
https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html
--8<---cut here---start->8---
Please write
Simon Tournier writes:
> Since I am French and it is easier for me to comment about my
> disagreements than the converse. ;-)
Feels like literally every national group makes this up about
themselves; British people are stereotypically very prone to
complaining, too :P
-- (
Hi Katherine,
Hi Liliana,
On Thu, Sep 7, 2023 at 1:39 PM Katherine Cox-Buday
wrote:
>
> Liliana, many of your responses in this thread are not OK.
Thank you for your candor! I also sensed some negativity in that
interaction. Both of you, please feel free to direct your comments to
me—privately
On 9/6/23 3:07 AM, Simon Tournier wrote:
As you said, we are all different, thus it means that any collaboration
cannot be full-frictionless. Because any social interaction implies
norms and standards. Norms and standards are by their definition
excluding.
For example, we communicate in
On 9/5/23 2:43 PM, Liliana Marie Prikler wrote:
Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
Liliana Marie Prikler writes:
Uhm, we have snippets?
Well, those are exclusive to Emacs :) And without regard to /that/
issue, I do think that there's a problem if the commit format is so
Hello,
On 2023-09-06 04:49, Maxim Cournoyer wrote:
Hi Katherine,
Katherine Cox-Buday writes:
On 9/5/23 10:01 AM, Simon Tournier wrote:
Well, somehow, I consider the commit message format similarly as
coding
style. We can discuss which one is better than the other when at the
end it only
Hello,
I wanted to add to this thread my 2 cents. As a person who has recently
(last months) made the first attempts at contributing.
To me, registrations and reliance on JS had always been an obstacle to
using web-based forges. This is one of the reasons I haven't been
contributing to existing
Am Mittwoch, dem 06.09.2023 um 10:52 -0700 schrieb Vagrant Cascadian:
> I always get tripped up with phases, modify-phases, etc. as there
> seem to be potentially four or more levels deep in some common code
> patterns... for example, a recent commit mentioning phases:
>
> commit
Maxim Cournoyer writes:
> Hi Vagrant,
>
> Vagrant Cascadian writes:
>
>> On 2023-09-06, Liliana Marie Prikler wrote:
>>> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
‘* foo/bar.scm new-package (inputs): add input’
stuff. I literally can never remember this format,
Am Dienstag, dem 05.09.2023 um 20:34 -0600 schrieb Katherine Cox-Buday:
> In the US, the phrase "I don't buy it" is usually the response to
> someone trying to trick you into something. This is a little hurtful
> because it's either saying:
>
> "You have an ulterior motive and are trying to
Am Mittwoch, dem 06.09.2023 um 00:04 +0200 schrieb wolf:
> On 2023-09-05 22:43:04 +0200, Liliana Marie Prikler wrote:
> > Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
> > > Liliana Marie Prikler writes:
> > > > Uhm, we have snippets?
> > >
> > > Well, those are exclusive to Emacs :)
Hi Vagrant,
Vagrant Cascadian writes:
> On 2023-09-06, Liliana Marie Prikler wrote:
>> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
>>> ‘* foo/bar.scm new-package (inputs): add input’
>>>
>>> stuff. I literally can never remember this format, no matter how many
>>> times I do it.
On 2023-09-06, Liliana Marie Prikler wrote:
> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
>> ‘* foo/bar.scm new-package (inputs): add input’
>>
>> stuff. I literally can never remember this format, no matter how many
>> times I do it. I'm reasonably sure square brackes go in there
Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
> ‘* foo/bar.scm new-package (inputs): add input’
>
> stuff. I literally can never remember this format, no matter how many
> times I do it. I'm reasonably sure square brackes go in there some
> where. It can take me quite a while to put
Hi,
Attila Lendvai writes:
>> also not as obvious (you search for lines added or removed or changed,
>> not easy language such as 'gnu: package-name: Add').
>
>
> i'm pretty sure that the source of the annoyance is not the strict
> format in the summary line, but the formal details in the
> > also not as obvious (you search for lines added or removed or changed,
> > not easy language such as 'gnu: package-name: Add').
>
>
>
> i'm pretty sure that the source of the annoyance is not the strict format in
> the summary line, but the formal details in the commit message body.
> also not as obvious (you search for lines added or removed or changed,
> not easy language such as 'gnu: package-name: Add').
i'm pretty sure that the source of the annoyance is not the strict format in
the summary line, but the formal details in the commit message body.
--
• attila lendvai
for opening the discussion and I am convinced that this
fruitful discussion will have a positive output reducing the current
friction for contributing.
Cheers,
simon
1: Re: How can we decrease the cognitive overhead for contributors?
Liliana Marie Prikler
Tue, 05 Sep 2023 22:43:04 +0200
id:
Hi Lily,
Liliana Marie Prikler writes:
> Instead, we have seen in this thread appeals to age, appeals to
> perceived lack of personal benefit, and now appeals to typing effort,
> none of which really make that great of an argument against the
> ChangeLog style, especially when they come in
On 9/5/23 5:55 PM, Simon Tournier wrote:
Hi Katherine,
I am fully aligned with the Survey proposal; at some past Guix Days I
remember discussing a kind of survey á la Haskell or Emacs surveys.
Well, such appears to me very informative to better know how to improve,
from user to contributor.
Hi Katherine,
Katherine Cox-Buday writes:
> On 9/5/23 10:01 AM, Simon Tournier wrote:
>
>> Well, somehow, I consider the commit message format similarly as coding
>> style. We can discuss which one is better than the other when at the
>> end it only reflects some artificial preferences and for
On 9/5/23 4:57 PM, Simon Tournier wrote:
Hi,
On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday
wrote:
Well, somehow, I consider the commit message format similarly as coding
style. We can discuss which one is better than the other when at the
end it only reflects some artificial
Hi Katherine,
I am fully aligned with the Survey proposal; at some past Guix Days I
remember discussing a kind of survey á la Haskell or Emacs surveys.
Well, such appears to me very informative to better know how to improve,
from user to contributor.
On Tue, 05 Sep 2023 at 12:00, Katherine
Hi,
On Wed, 06 Sep 2023 at 00:11, wolf wrote:
> But I guess this was supposed to be taken as "run make check' and make sure
> nothing new is broken". Is there a command for that?
Yes taken like that. :-)
And nothing I am aware. I agree that the situation with “make check” is
imperfect.
"(" writes:
> Liliana Marie Prikler writes:
>> Uhm, we have snippets?
>
> Well, those are exclusive to Emacs :) And without regard to /that/
> issue, I do think that there's a problem if the commit format is so
> complex that it's not trivial for anyone new to the project to write
> them out
Hi,
On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday
wrote:
>> Well, somehow, I consider the commit message format similarly as coding
>> style. We can discuss which one is better than the other when at the
>> end it only reflects some artificial preferences and for the sake of any
>>
1 - 100 of 231 matches
Mail list logo
