On Mon, Feb 05, 2024 at 10:50:36PM +, Steve George wrote:
> 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. Thi
Giovanni Biscuolo writes:
> [[PGP Signed Part:Signature made by expired key D37D0EA7CECC3912 Giovanni
> Biscuolo (Xelera) ]]
> Hi,
>
> Giovanni Biscuolo writes:
>
> [...]
>
The first thing we need is a server side git post-receive hook on
Savannah, I've opened the sr#110928 support r
Hi Vagrant,
Vagrant Cascadian writes:
[...]
> This is why I think it is important for projects to have some sort of
> namespacing for this sort of thing; I am not really opinionated on the
> exact details, other than it not conflicting with Debian's terribly
> generic entirely un-namespaced his
On 2023-09-14, Giovanni Biscuolo wrote:
> Maxim Cournoyer writes:
>> I like the 'Closes: ' trailer idea; it's simple. However, it'd need to
>> be something added locally, either the user typing it out (unlikely for
>> most contributors) or via some mumi wizardry (it's unlikely that all
>> users w
On 2023-09-15, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 14.09.2023 um 15:51 -0700 schrieb Vagrant Cascadian:
>> On 2023-09-10, Liliana Marie Prikler wrote:
>> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
>> > Cascadian:
>> > > I am much more comfortable with the "Fixes" c
Hi Giovanni,
Before commenting, let me repeat. ;-)
That’s said, I am not against the proposal. I just have mixed
feelings and before deploying I strongly suggest to review if
the proposal covers the intent.
On Fri, 15 Sep 2023 at 09:16, Giovanni Biscuolo wrote:
> Befo
Hello Simon,
thank you for havig listed possible troubles.
Before commenting, just let me repeat that we are _copying_ the
'Change-Id' idea (and related possible implementation issues) from
Gerrit:
https://gerrit-review.googlesource.com/Documentation/user-changeid.html
This means that Somewhere
Am Donnerstag, dem 14.09.2023 um 15:51 -0700 schrieb Vagrant Cascadian:
> On 2023-09-10, Liliana Marie Prikler wrote:
> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
> > Cascadian:
> > > I am much more comfortable with the "Fixes" convention of:
> > >
> > > Fixes: https://issues
On 2023-09-10, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>> I am much more comfortable with the "Fixes" convention of:
>>
>> Fixes: https://issues.guix.gnu.org/NNN
> I like the idea, but we should also consider the bugs.gnu.org address
Hello,
Le 14 septembre 2023 12:30:41 GMT-04:00, Vagrant Cascadian
a écrit :
[…]
>> I doubt the Change-Id idea would help much closing *bugs* on the
>> bug-guix tracker, but I'd expect it to be useful to close already merged
>> (but forgotten on the guix-patches tracker) *patches*.
>
>Well, all
Am Donnerstag, dem 14.09.2023 um 11:42 +0200 schrieb Giovanni Biscuolo:
> OK! :-) Let's see how this relates to the 2 use cases we are talking
> about:
>
> 1. Use "Fixes:" (et al) in commit msg to tell "the hook" to close the
> bug.
>
> This "action" implies that the commit we are pushing upstre
Hi,
On Thu, 14 Sep 2023 at 12:27, Giovanni Biscuolo wrote:
> Please can you expand what troubles do you see in automatically adding
> 'Change-Id:' using a hook-commit-msg like
> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
> ?
1. The hook must be installed.
2. T
On 2023-09-13, Maxim Cournoyer wrote:
> Vagrant Cascadian writes:
>> On 2023-09-09, Maxim Cournoyer wrote:
>>> The Change-Id stays the same unless you manually edit it out of your
>>> commit message when amending / rebasing, so the commit hash may change
>>> while the Change-Id stays the same. So
Maxim Cournoyer writes:
[...]
> I like the 'Closes: ' trailer idea; it's simple. However, it'd need to
> be something added locally, either the user typing it out (unlikely for
> most contributors) or via some mumi wizardry (it's unlikely that all
> users will use mumi), which means its usage (
Simon Tournier writes:
[...]
>> maybe ChangeIds really trump the explicit tags proposed by Giovanni
>> or myself here. Whether that justifies the cognitive overhead of
>> juggling them around on every submission remains to be shown or
>> disproven.
>
> I agree. I am not convinced by the benef
Hi Liliana
Liliana Marie Prikler writes:
> Am Mittwoch, dem 13.09.2023 um 11:27 -0400 schrieb Maxim Cournoyer:
[...]
> I do wonder how the ChangeId would work in practice.
It's a «tag to track commits across cherry-picks and rebases.»
It is used by Gerrit to identify commits that belong to t
Hi Maxim and Vagrant,
I'm sorry for some of the inconprehensions.
Finally I think we got a useful design overall for the _two_ user cases
and the related pieces of metadata and algorithms, now it's time for
_two_ implementations proposals, that also means _code_...
If nihil obstat, I'm going to
Hello,
Am Wed, Sep 13, 2023 at 09:14:52PM +0200 schrieb Liliana Marie Prikler:
> I do wonder how the ChangeId would work in practice. Since it's not
> really assigned by the committer, it would have to be generated "on the
> fly" and attached to the mail in between, which could result in all
> ki
Hi,
Simon Tournier writes:
> Hi,
>
> On Wed, 13 Sep 2023 at 21:14, Liliana Marie Prikler
> wrote:
>
>> I do wonder how the ChangeId would work in practice. Since it's not
>> really assigned by the committer, it would have to be generated "on the
>> fly" and attached to the mail in between, wh
Hi,
On Wed, 13 Sep 2023 at 21:14, Liliana Marie Prikler
wrote:
> I do wonder how the ChangeId would work in practice. Since it's not
> really assigned by the committer, it would have to be generated "on the
> fly" and attached to the mail in between, which could result in all
> kinds of nasty
Am Mittwoch, dem 13.09.2023 um 11:27 -0400 schrieb Maxim Cournoyer:
> For just closing cross-referenced bugs, I agree. For closing
> forgotten, already merged issues on guix-patches we'd need the
> Change-Id and a tool able to map Change-Ids -> issue number (mumi is
> in the best place to do so).
Hi,
Vagrant Cascadian writes:
> On 2023-09-09, Maxim Cournoyer wrote:
>> Vagrant Cascadian writes:
Did you see my message about integrating a commit-hook similar to what
Gerrit uses? It produces unique ID such as:
--8<---cut here---start-
t;> or guix trackers or vice-versa (git log --grep='Change-Id=XXXX'), as
>> noted by Giovanni.
> The thing is, we're discussing the same basic workflow (which you lay
> out below), just different kinds of metadata that we'd have to attach
> to our commits. IIUC Chan
Hi Giovanni,
Giovanni Biscuolo writes:
[...]
Liliana Marie Prikler writes:
>
> WDYT about the following
> Applies: [patch]
> Closes: [patch]
> Resolves: [patch]
> Done: [patch]
[...]
> Anyway, I agree with Liliana that having more keyworks will help
Hi Liliana and Maxim,
Liliana Marie Prikler writes:
[...]
> The thing is, we're discussing the same basic workflow
No, we are discussing two (complementary) workflows:
1. the one I suggested to add a "footer-metadata-field" named
Fix/Fixes/Close/Closes/whatever that will al
On 2023-09-09, Maxim Cournoyer wrote:
> Vagrant Cascadian writes:
>>> Did you see my message about integrating a commit-hook similar to what
>>> Gerrit uses? It produces unique ID such as:
>>>
>>> --8<---cut here---start->8---
>>> Change-Id: I9b86781869d80eda34
The thing is, we're discussing the same basic workflow (which you lay
out below), just different kinds of metadata that we'd have to attach
to our commits. IIUC ChangeIds need to actually be carried around by
the committers as they e.g. rewrite patches (rebasing, squashing, what
have you)
Hi Maxim and Liliana,
Maxim Cournoyer writes:
>>> Liliana Marie Prikler writes:
>>> > WDYT about the following
>>> > Applies: [patch]
>>> > Closes: [patch]
>>> > Resolves: [patch]
>>> > Done: [patch]
[...]
>> I'm just asking which wording you prefer. For the tracker, they'd mean
Hi Liliana,
Liliana Marie Prikler writes:
> Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer:
>> Hi,
>>
>> Liliana Marie Prikler writes:
>>
>> [...]
>>
>> > Maybe make that bug-guix so that it matches with the mailing list
>> > name,
>> > though we also need a wording for when a
Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer:
> Hi,
>
> Liliana Marie Prikler writes:
>
> [...]
>
> > Maybe make that bug-guix so that it matches with the mailing list
> > name,
> > though we also need a wording for when a patch is not a bug, e.g. a
> > simple package upgrad
Hi,
Liliana Marie Prikler writes:
[...]
> Maybe make that bug-guix so that it matches with the mailing list name,
> though we also need a wording for when a patch is not a bug, e.g. a
> simple package upgrade.
>
> WDYT about the following
> Applies: [patch]
> Closes: [patch]
> Resolves:
Am Montag, dem 11.09.2023 um 10:09 +0200 schrieb Giovanni Biscuolo:
> Hi!
>
> Liliana Marie Prikler writes:
>
> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
> > Cascadian:
> > > I am much more comfortable with the "Fixes" convention of:
> > >
> > > Fixes: https://issues.guix
Hi Maxim,
Maxim Cournoyer writes:
[...]
>> If there is enough consensus I volunteer to collect ideas and send a
>> feature request to the mumi and/or Debbugs devels (if we need Debbugs
>> patches I guess it will be a long term goal)
>
> I don't think any changes to Debbugs would be necessary.
Hi Simon
Simon Tournier writes:
[...]
>> is enough, but (is:open and tag:patch,moreinfo) is better:
[...]
>> We could also add a feature to have "saved searches" in mumi web and CLI
>> interfaces to help with this task.
>
> Well, the Mumi CLI, “guix shell mumi” and then “mumi search”, should
Hi,
On Mon, 11 Sep 2023 at 09:37, Giovanni Biscuolo wrote:
> A more useful mumi (web or CLI) query to search for duplicates would be:
>
> is:open tag:patch subject:
[...]
> is enough, but (is:open and tag:patch,moreinfo) is better:
>
> https://issues.guix.gnu.org/search?query=is%3Aopen+tag%
Hi,
Simon Tournier writes:
> Hi Maxim,
>
> Thanks for the explanations.
>
> On Mon, 11 Sept 2023 at 15:47, Maxim Cournoyer
> wrote:
>
>> > 2. How is Change-Id linked to #65280?
>>
>> Each patch submission ("issue") can have one or multiple commits. We'd
>> know for sure the series was merged
Hi Maxim,
Thanks for the explanations.
On Mon, 11 Sept 2023 at 15:47, Maxim Cournoyer
wrote:
> > 2. How is Change-Id linked to #65280?
>
> Each patch submission ("issue") can have one or multiple commits. We'd
> know for sure the series was merged (and thus can be closed) when the
> set of 'C
Hi Giovanni,
Giovanni Biscuolo writes:
> Hi Maxim,
>
> Maxim Cournoyer writes:
>
> [...]
>
>>> c. how do we get the issue number of a patch containing "Change-Id"? [1]
>>
>> We'd have to search through the currently opened patches issues; I
>> assume using a tool like the 'mumi' command we alre
Hi Giovanni,
Giovanni Biscuolo writes:
> Hi!
>
> Liliana Marie Prikler writes:
>
>> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>>> I am much more comfortable with the "Fixes" convention of:
>>>
>>> Fixes: https://issues.guix.gnu.org/NNN
>
> OK, I understand Vagra
Hi Simon,
Simon Tournier writes:
> Hi Maxim,
>
> On Sat, 09 Sep 2023 at 19:50, Maxim Cournoyer
> wrote:
>
--8<---cut here---start->8---
random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
git hash-object --stdin)
--
Hi Maxim,
On Sat, 09 Sep 2023 at 19:50, Maxim Cournoyer wrote:
>>> --8<---cut here---start->8---
>>> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
>>> git hash-object --stdin)
>>> --8<---cut here---end--
Hi!
Liliana Marie Prikler writes:
> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>> I am much more comfortable with the "Fixes" convention of:
>>
>> Fixes: https://issues.guix.gnu.org/NNN
OK, I understand Vagrant's concerns: we need a _namespaced_ URI, but
there is
Hi Maxim,
Maxim Cournoyer writes:
[...]
>> c. how do we get the issue number of a patch containing "Change-Id"? [1]
>
> We'd have to search through the currently opened patches issues; I
> assume using a tool like the 'mumi' command we already have could do
> that.
It would be fantastic if we
Hello Vagrant,
sorry for the delay with this reply (maybe meanwhile someone else have
already done all or some of my considerations)
Vagrant Cascadian writes:
[...]
>> The point is that triaging is a (boring) activity that Someone™ should
>> perform, sooner or later (as Vagrant did with the bu
Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
> I am much more comfortable with the "Fixes" convention of:
>
> Fixes: https://issues.guix.gnu.org/NNN
I like the idea, but we should also consider the bugs.gnu.org address
here as well as the convention of putting it into
Hi Vagrant,
Vagrant Cascadian writes:
[...]
>> Did you see my message about integrating a commit-hook similar to what
>> Gerrit uses? It produces unique ID such as:
>>
>> --8<---cut here---start->8---
>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
>
Hi Simon,
Simon Tournier writes:
> Hi,
>
> On Wed, 06 Sep 2023 at 22:01, Maxim Cournoyer
> wrote:
>
>> We could use Gerrit's commit hook that adds a unique ID as a git
>> trailer. Then it should become possible to
>
> Do we still already have Gerrit running?
I was not suggesting to host Gerr
Hi Giovanni,
Giovanni Biscuolo writes:
[...]
>> We could use Gerrit's commit hook that adds a unique ID as a git
>> trailer.
>
> Do you mean "commit-msg" hook as documented here:
> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
> ?
>
>
> The Gerrit Code Review sup
Hi Vagrant!
On Thu, Sep 7, 2023 at 9:13 AM Vagrant Cascadian wrote:
>
> So... I maintain the guix package in Debian, and want to make sure
> that whatever bug-closing indicator guix upstream uses, does not end up
> triggering when I push new upstream versions to salsa.debian.org ... and
> sta
On 2023-09-07, Giovanni Biscuolo wrote:
> Hi Maxim and Ludovic,
> Maxim Cournoyer writes:
>> Giovanni Biscuolo writes:
..
>>> When I asket I though the best way would be to scan for a string like
>>> "Close #" in the commit message (the committer should add
>>> such a string) but probably this ca
On 2023-09-07, Maxim Cournoyer wrote:
> Felix Lechner writes:
>> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo wrote:
>>>
>>> close the bugs that are listed in
>>> the commit message
...
> Did you see my message about integrating a commit-hook similar to what
> Gerrit uses? It produces unique
On 2023-09-07, Giovanni Biscuolo wrote:
> Christopher Baines writes:
>
>> Giovanni Biscuolo writes:
>
> [...]
>
>>> 20 bugs with messages similar to this one:
>>>
>>>
>>> rofi-wayland was added in:
>>>
>>> 04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.
>>>
>>> And updated to a
Hi,
On Wed, 06 Sep 2023 at 22:01, Maxim Cournoyer wrote:
> We could use Gerrit's commit hook that adds a unique ID as a git
> trailer. Then it should become possible to
Do we still already have Gerrit running?
Cheers,
simon
Hi,
Giovanni Biscuolo writes:
[...]
>>> The first thing we need is a server side git post-receive hook on
>>> Savannah, I've opened the sr#110928 support request:
>>> https://savannah.nongnu.org/support/index.php?110928
>>
>> It's something that the Savannah folks would need to maintain
>> them
Hi Felix,
Felix Lechner writes:
> Hi Gio',
>
> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo wrote:
>>
>> close the bugs that are listed in
>> the commit message
>
> Perhaps you'd like to see Debian's hook [1] for the Salsa web forge
> (which is controversially based on Gitlab).
[...]
Than
Hi Maxim,
Maxim Cournoyer writes:
> Simon Tournier writes:
[...]
>> Maybe patchwork already running (I think) could help, trying to
>> regularly rebase the branch dedicated to the submission on the top of
>> master, then if all is fine, somehow the two heads from the master
>> branch and the
Hi,
Felix Lechner writes:
> Hi Gio',
>
> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo wrote:
>>
>> close the bugs that are listed in
>> the commit message
>
> Perhaps you'd like to see Debian's hook [1] for the Salsa web forge
> (which is controversially based on Gitlab).
>
> The regex does
Hi Gio',
On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo wrote:
>
> close the bugs that are listed in
> the commit message
Perhaps you'd like to see Debian's hook [1] for the Salsa web forge
(which is controversially based on Gitlab).
The regex does not work properly for more than two bugs, ho
Hi Simon,
Simon Tournier writes:
> On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer
> wrote:
>
>>> Let's avoid manual gardening as much as possible! :-)
>>
>> I like the idea!
>
> I think that automatizing is not trivial. Sadly.
If we "restrict" the automation to "close the bugs that are listed
Hi Maxim and Ludovic,
I'm including you, Ludovic, becaus in the past you requested a similar
git hook installation for Guix and maybe you have more info
Maxim Cournoyer writes:
> Giovanni Biscuolo writes:
[...]
OK, I really found the wrong examples as Christopher pointed out, but my
proposal
Hi Christopher,
[note: I'm deleting the "In-Reply-To:" header and changing subject to
try to start a new thread]
Christopher Baines writes:
> Giovanni Biscuolo writes:
[...]
>> 20 bugs with messages similar to this one:
>>
>>
>> rofi-wayland was added in:
>>
>> 04b5450ad852735dfa50961d3afc
Hi,
Simon Tournier writes:
> Hi,
>
> On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer
> wrote:
>
>>> Let's avoid manual gardening as much as possible! :-)
>>
>> I like the idea!
>
> I think that automatizing is not trivial. Sadly.
>
> There are many corner cases:
>
> 1. series as attachement
>
Hi,
On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer wrote:
>> Let's avoid manual gardening as much as possible! :-)
>
> I like the idea!
I think that automatizing is not trivial. Sadly.
There are many corner cases:
1. series as attachement
2. not all the series is applied
3. commit message
Hi Giovanni,
Giovanni Biscuolo writes:
> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages simil
Giovanni Biscuolo writes:
> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages similar to this on
Hello,
often bug reports related to patches are left open even after the
patch/patchset have been applied, the last example is a batch of Debbugs
manual gardening from Vagrant last Fri and Sat when he closed more than
20 bugs with messages similar to this one:
--8<---cut here-
> I don't think automatically closing older issues is helpful, they still
> need looking at.
Or instead of closing them, put the patch into a state that is not open. Like
an archived state or some other state that does not require action until
someone takes ownership of the issue and resolves it
"jgart" writes:
> Hi Guixers,
>
> Andreas' detailed a nice workflow for reviewing patches in a previous thread*:
>
> ```
> git clone https://git.guix-patches.cbaines.net/guix-patches/
> git checkout issue-x
> git format-patch ...
> then in
>> Old tickets are not kept around.
Hi,
Oh ok, old tickets were never included instead of old tickets being deleted.
I'm not familiar with this code yet.
Thanks for the clarification.
Hello jgart,
Am Mon, Sep 04, 2023 at 05:48:05PM + schrieb jgart:
> Old tickets are not kept around.
> For example, A branch for ticket 51810* does not exist anymore.
this is probably due to the fact that the git repo did not yet exist
at the time. The oldest issue I see is 60286 from December
Hi Guixers,
Andreas' detailed a nice workflow for reviewing patches in a previous thread*:
```
git clone https://git.guix-patches.cbaines.net/guix-patches/
git checkout issue-x
git format-patch ...
then in the development checkout of Guix:
git am ...; make; ./pre-inst-env guix build
`
ranch. Instead, I would change the workflow:
1. Only folks who provide substitutes or their delegates can push to
master. That would ensure the highest availability of substitutes the
project can muster. I would rename the master branch to 'ready' or
'installable'. The people I
> > 1) the code that will be run as the init process in a Guix System
> >
> > 2) the code that the Guix codebase is compiled against
>
> AFAICT, these two use the same shepherd -- i.e., the shepherd from
> the 'shepherd-configuration' record.
>
> To see what shepherd the 'start' and 'stop' procedur
Hi!
The Shepherd is decoupled from Guix. In general, when hacking on it,
you should think of it as an independent piece of software, a user of
which is Guix.
A corollary is that there are well-defined interfaces between the two.
Usually, you cannot add a new interface in the Shepherd an expect t
On 2022-03-01 08:59, Attila Lendvai wrote:
Hi Attlila thanks for working on this. For me your proposal seems to
make sense (but I guess input from more folks would be needed).
--
Kinds regards Oliver Propst
https://twitter.com/Opropst
Attila Lendvai schreef op di 01-03-2022 om 07:59 [+]:
> 1) the code that will be run as the init process in a Guix System
>
> 2) the code that the Guix codebase is compiled against
AFAICT, these two use the same shepherd -- i.e., the shepherd from
the 'shepherd-configuration' record.
To see
;ll propose an idea
here that may make the workflow even slicker.
there seems to be 3 ways in which Shepherd is influencing the build results of
Guix:
1) the code that will be run as the init process in a Guix System
2) the code that the Guix codebase is compiled against
3) the Shepherd packag
Hi,
zimoun writes:
[...]
>> All in all, it’s probably not as worrisome as it first seems. However,
>> it’s worth keeping in mind when reviewing a package.
>
> I agree with a minor comment. From my opinion, not enough patches are
> going via guix-patches and are pushed directly.
>
> For instan
Sorry for duplicated email,
On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote:
> I don’t think we should have a security-updates
> branch, because the role of that branch is effectively taken by
> staging.
I don't think that's the case because staging is documented for things
that do not ma
o question becomes confrontational way rather than in a friendly way I
stop being able to. I feel like I have taken into account many
criticism and changed my workflow due to that. I am glad people help me
improve the contributions I make to GNU Guix.
This thread is a proposal, like all others wer
Hi Léo,
> Hello Ludo,
>
> On Wed, 2021-03-31 at 23:29 +0200, Ludovic Courtès wrote:
>> It’s unacceptable to call someone “obsessed” just because you
>> disagree
>> and calling Simon’s comments “harassment” is equally inappropriate.
>
> I really do feel harassed by their comments, it's not just b
Hello Ludo,
On Wed, 2021-03-31 at 23:29 +0200, Ludovic Courtès wrote:
> It’s unacceptable to call someone “obsessed” just because you
> disagree
> and calling Simon’s comments “harassment” is equally inappropriate.
I really do feel harassed by their comments, it's not just because I
disagree, it'
Léo,
Léo Le Bouter skribis:
> I feel harassed by your comments because you obsessed on this zstd
> issue and try to make it the cause of some other problems you saw
> without any evidence.
It’s unacceptable to call someone “obsessed” just because you disagree
and calling Simon’s comments “haras
On Tue, 2021-03-30 at 13:48 +0200, zimoun wrote:
> Ahah, I am happy to know it. I hope it is because a
> “miscommunication»
> and not because you do not carefully read or because maybe you only
> see
> through the tiny lens of known security vulnerabilities. From my
> opinion, your point of view
On Sat, 27 Mar 2021 at 15:14, Léo Le Bouter wrote:
> but you
> cannot put forward the arguments you've made, they do not work.
Ahah, I am happy to know it. I hope it is because a “miscommunication»
and not because you do not carefull
On Sat, 2021-03-27 at 14:56 +0100, zimoun wrote:
> Oh, I am a big boy and I can think whatever I want! :-)
>
> Kidding aside.
...
>
> First, what does it mean «risk»? How do you evaluate it? Is it a
> relative evaluation or an absolute one?
Most if not all users do not want their machines to
On Sat, 27 Mar 2021 at 13:42, Léo Le Bouter wrote:
> On Sat, 2021-03-27 at 13:29 +0100, zimoun wrote:
>> And as I said elsewhere, “to me, security is important. But it's
>> no less important than everything *else* that is also important!“, so
>> personally I am not convinced that security updates
Thanks for your feedback.
On Sat, 2021-03-27 at 13:29 +0100, zimoun wrote:
> And as I said elsewhere, “to me, security is important. But it's
> no less important than everything *else* that is also important!“, so
> personally I am not convinced that security updates deserve a special
> treatment
Hi Léo,
On Fri, 26 Mar 2021 at 21:10, Léo Le Bouter wrote:
> For these reasons, I would like to propose a new branch called
> security-updates that would be based on master where we queue security
> fixes that introduce any arbitrary number of rebuilds without using
> grafts.
>
> We would merge
Léo Le Bouter writes:
> On Fri, 2021-03-26 at 22:13 +, Christopher Baines wrote:
>> Can you clarify what specific problem or problems you're proposing
>> this
>> security-updates branch to address?
>
> Substitute availability of security updates when they are released,
> without causing big
On Fri, 2021-03-26 at 22:13 +, Christopher Baines wrote:
> Can you clarify what specific problem or problems you're proposing
> this
> security-updates branch to address?
Substitute availability of security updates when they are released,
without causing big rebuilds on master for users before
Léo Le Bouter writes:
> There is two ways to ship security fixes to packages:
>
> 1. Update to a patched version if upstream provides one
> 2. Apply or backport individual patches to fix the issues in the
> shipped version
>
> Grafts are most reliable for 2. but there's cases where using 2. is
>
Hello!
There is two ways to ship security fixes to packages:
1. Update to a patched version if upstream provides one
2. Apply or backport individual patches to fix the issues in the
shipped version
Grafts are most reliable for 2. but there's cases where using 2. is
lots of work and we can't affo
Hi Chris,
On Fri, 05 Mar 2021 at 10:34, Christopher Lemmer Webber
wrote:
> zimoun writes:
>> On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber
>> wrote:
>>
>>> I wonder if we should formalize it. What about adding a section to the
>>> "Contributing" section of the manual explaining wha
zimoun writes:
> Hi, Chris,
>
> On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber
> wrote:
>
>> I wonder if we should formalize it. What about adding a section to the
>> "Contributing" section of the manual explaining what the different
>> branches are, and when you have a patch that's b
Hi, Chris,
On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber
wrote:
> I wonder if we should formalize it. What about adding a section to the
> "Contributing" section of the manual explaining what the different
> branches are, and when you have a patch that's been approved, when to
> pus
Thoughts?
- Chris
Leo Famulari writes:
> Based on experiences with the last "staging" cycle and discussions at
> the most recent Guix Day meeting [0], we've changed the branching
> workflow.
>
> The default branch names remain "core-updates" and "stagi
Leo,
On 2021-02-13 19:21, Leo Famulari wrote:
Due to overwhelming demand both on and off list, the bikeshed has been
repainted.
...and the second-floor window (it's... a big shed?) no longer reads
'Way Out ->'.
One can trivialise anything.
Genuine thanks for pushing for improvement,
T G-R
On Sat, Feb 13, 2021 at 12:24:50PM +0100, Hartmut Goebel wrote:
> Am 12.02.21 um 21:49 schrieb Andreas Enge:
> > From what I understood of the discussion, I would also go with Tobias's and
> > Efraim's suggestion: There is a core-updates branch that is constantly open
> > and where people can push
Am 12.02.21 um 21:49 schrieb Andreas Enge:
From what I understood of the discussion, I would also go with Tobias's and
Efraim's suggestion: There is a core-updates branch that is constantly open
and where people can push; this does not seem to leave a possibility of
mistake, almost by definition
1 - 100 of 156 matches
Mail list logo
