Re: branch master updated: gnu: eudev: Use new package style.

Re: branch master updated: gnu: eudev: Use new package style.

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]


guix-commits@gnu.org writes:

> This is an automated email from the git hooks/post-receive script.
>
> lilyp pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
>      new 7ff003bcbf gnu: eudev: Use new package style.
> 7ff003bcbf is described below
>
> commit 7ff003bcbf388677c7c85b1709c58f41f84b9947
> Author: Felix Lechner <felix.lechner@lease-up.com>
> AuthorDate: Sun May 28 16:28:20 2023 -0700
>
>     gnu: eudev: Use new package style.
>     
>     * gnu/packages/linux.scm (eudev)[arguments]: Convert to list of G-Expressions.
>     [native-inputs]: Drop labels.
>     
>     Signed-off-by: Liliana Marie Prikler <liliana.prikler@gmail.com>
> ---
>  gnu/packages/linux.scm | 94 ++++++++++++++++++++++++--------------------------
>  1 file changed, 45 insertions(+), 49 deletions(-)

These changes do look to affect the derivation for eudev, and eudev also
has too many dependents to update on the master branch.

→ guix refresh -l eudev
Building the following 1913 packages would ensure 4138 dependent
packages are rebuilt: ...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: branch master updated: gnu: eudev: Use new package style.

[Liliana Marie Prikler]

Am Montag, dem 29.05.2023 um 19:28 +0100 schrieb Christopher Baines:
> 
> guix-commits@gnu.org writes:
> 
> > This is an automated email from the git hooks/post-receive script.
> > 
> > lilyp pushed a commit to branch master
> > in repository guix.
> > 
> > The following commit(s) were added to refs/heads/master by this
> > push:
> >      new 7ff003bcbf gnu: eudev: Use new package style.
> > 7ff003bcbf is described below
> > 
> > commit 7ff003bcbf388677c7c85b1709c58f41f84b9947
> > Author: Felix Lechner <felix.lechner@lease-up.com>
> > AuthorDate: Sun May 28 16:28:20 2023 -0700
> > 
> >     gnu: eudev: Use new package style.
> >     
> >     * gnu/packages/linux.scm (eudev)[arguments]: Convert to list of
> > G-Expressions.
> >     [native-inputs]: Drop labels.
> >     
> >     Signed-off-by: Liliana Marie Prikler
> > <liliana.prikler@gmail.com>
> > ---
> >  gnu/packages/linux.scm | 94 ++++++++++++++++++++++++--------------
> > ------------
> >  1 file changed, 45 insertions(+), 49 deletions(-)
> 
> These changes do look to affect the derivation for eudev, and eudev
> also has too many dependents to update on the master branch.
> 
> → guix refresh -l eudev
> Building the following 1913 packages would ensure 4138 dependent
> packages are rebuilt: ...
Should I revert it?  Even with the mass rebuild, my intuition was that
it'd be okay since it's no functional change and core-updates was
dropped in favour of teams (with no particular team being responsible
for udev afaik).

Cheers

Re: branch master updated: gnu: eudev: Use new package style.

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]


Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 29.05.2023 um 19:28 +0100 schrieb Christopher Baines:
>> 
>> guix-commits@gnu.org writes:
>> 
>> > This is an automated email from the git hooks/post-receive script.
>> > 
>> > lilyp pushed a commit to branch master
>> > in repository guix.
>> > 
>> > The following commit(s) were added to refs/heads/master by this
>> > push:
>> >      new 7ff003bcbf gnu: eudev: Use new package style.
>> > 7ff003bcbf is described below
>> > 
>> > commit 7ff003bcbf388677c7c85b1709c58f41f84b9947
>> > Author: Felix Lechner <felix.lechner@lease-up.com>
>> > AuthorDate: Sun May 28 16:28:20 2023 -0700
>> > 
>> >     gnu: eudev: Use new package style.
>> >     
>> >     * gnu/packages/linux.scm (eudev)[arguments]: Convert to list of
>> > G-Expressions.
>> >     [native-inputs]: Drop labels.
>> >     
>> >     Signed-off-by: Liliana Marie Prikler
>> > <liliana.prikler@gmail.com>
>> > ---
>> >  gnu/packages/linux.scm | 94 ++++++++++++++++++++++++--------------
>> > ------------
>> >  1 file changed, 45 insertions(+), 49 deletions(-)
>> 
>> These changes do look to affect the derivation for eudev, and eudev
>> also has too many dependents to update on the master branch.
>> 
>> → guix refresh -l eudev
>> Building the following 1913 packages would ensure 4138 dependent
>> packages are rebuilt: ...
> Should I revert it?  Even with the mass rebuild, my intuition was that
> it'd be okay since it's no functional change and core-updates was
> dropped in favour of teams (with no particular team being responsible
> for udev afaik).

I think there is disagreement about this (including at least some
maintainers thinking differently), but I'm of the opinion that while
there has been discussion about stopping using core-updates, people
should follow the currently documented process, and for now that's still
using staging/core-updates [1].

1: https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html#index-rebuild-scheduling-strategy

As for reverting it, I'm somewhat indifferent. I'm more interested in
the longer term cost of making changes like this than the temporary
drops in substitute availability.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: branch master updated: gnu: eudev: Use new package style.

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Liliana,

On Mon, May 29, 2023 at 12:26 PM Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:
>
> Should I revert it?

Being partially responsible for provoking you into this commit,
perhaps it is acceptable if I likewise recommend reverting it.

> Even with the mass rebuild, my intuition was that
> it'd be okay

Eudev affects a boatload of packages. I rebuilt them locally several times.

> with no particular team being responsible
> for udev afaik

If my presence is not too much of a nuisance, I'd be honored to work
on udev together with you. You alone reviewed my patch series, and
while I disagree with some of your positions, I believe that you are
one of Guix's most talented contributors and programmers.

I also believe my interest in Guix was fostered in large part by a
presentation you once gave.

Kind regards
Felix

Re: branch master updated: gnu: eudev: Use new package style.

[Liliana Marie Prikler]

Am Montag, dem 29.05.2023 um 20:29 +0100 schrieb Christopher Baines:
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Montag, dem 29.05.2023 um 19:28 +0100 schrieb Christopher
> > Baines:
> > > 
> > > guix-commits@gnu.org writes:
> > > 
> > > > This is an automated email from the git hooks/post-receive
> > > > script.
> > > > 
> > > > lilyp pushed a commit to branch master
> > > > in repository guix.
> > > > 
> > > > The following commit(s) were added to refs/heads/master by this
> > > > push:
> > > >      new 7ff003bcbf gnu: eudev: Use new package style.
> > > > 7ff003bcbf is described below
> > > > 
> > > > commit 7ff003bcbf388677c7c85b1709c58f41f84b9947
> > > > Author: Felix Lechner <felix.lechner@lease-up.com>
> > > > AuthorDate: Sun May 28 16:28:20 2023 -0700
> > > > 
> > > >     gnu: eudev: Use new package style.
> > > >     
> > > >     * gnu/packages/linux.scm (eudev)[arguments]: Convert to
> > > > list of
> > > > G-Expressions.
> > > >     [native-inputs]: Drop labels.
> > > >     
> > > >     Signed-off-by: Liliana Marie Prikler
> > > > <liliana.prikler@gmail.com>
> > > > ---
> > > >  gnu/packages/linux.scm | 94 ++++++++++++++++++++++++----------
> > > > ----
> > > > ------------
> > > >  1 file changed, 45 insertions(+), 49 deletions(-)
> > > 
> > > These changes do look to affect the derivation for eudev, and
> > > eudev also has too many dependents to update on the master
> > > branch.
> > > 
> > > → guix refresh -l eudev
> > > Building the following 1913 packages would ensure 4138 dependent
> > > packages are rebuilt: ...
> > Should I revert it?  Even with the mass rebuild, my intuition was
> > that it'd be okay since it's no functional change and core-updates
> > was dropped in favour of teams (with no particular team being
> > responsible for udev afaik).
> 
> I think there is disagreement about this (including at least some
> maintainers thinking differently), but I'm of the opinion that while
> there has been discussion about stopping using core-updates, people
> should follow the currently documented process, and for now that's
> still using staging/core-updates [1].
Fair enough, I will refrain from pushing mass rebuilds directly to
master.

> 1:
> https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html#index-rebuild-scheduling-strategy
> 
> As for reverting it, I'm somewhat indifferent. I'm more interested in
> the longer term cost of making changes like this than the temporary
> drops in substitute availability.
You mean as a precedent for similar commits in the future or as a way
of involuntarily breaking other packages?  As already stated, I only
pushed the commit because I was quite sure that all rebuilds would
succeed.

Cheers

Re: branch master updated: gnu: eudev: Use new package style.

[Attila Lendvai]

> > As for reverting it, I'm somewhat indifferent. I'm more interested in
> > the longer term cost of making changes like this than the temporary
> > drops in substitute availability.
> 
> You mean as a precedent for similar commits in the future or as a way
> of involuntarily breaking other packages? As already stated, I only
> pushed the commit because I was quite sure that all rebuilds would
> succeed.


a less frequent drop in substitute availability on master would considerably elevate my satisfaction with guix as a user. and in my reading that is the cost that Christopher talks about here.

it's rather disruptive on my workflow when i want to deploy something from my channel to my servers, but due to missing substitutes i need to edit the channels.scm file, pick a commit in the past... and make sure i pick it in sync with That-Other-Channel... then hope that the past commit i picked is covered by substitutes, because currently it's not predictable which commits are fully built by the build farm... then issue a `guix pull --allow-downgrades` to revert the guix channel... and then repeat it all if i picked a commit that is also not covered well...

my 0.02 is that it shouldn't be an either-or choice between 1) teams and topic branches, and 2) a core-updates-like staging branch. the latter should be employed, if for nothing else, to keep substitute availability high on master.

maybe with the addition of team branches a core-updates branch would be much more manageable? and it'd be easier to merge it more frequently? then it could be a home for commits that are semantically simple, but expensive to build.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If he controls your ideas he will soon control your actions, because every action is preceded by an idea.”
	— Silvano Arieti (1914–1981), 'The Will to Be Human'

Workflow ideas [Was: branch master updated: gnu: eudev: Use new package style.]

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Attila,

On Tue, May 30, 2023 at 12:49 PM Attila Lendvai <attila@lendvai.name> wrote:
>
> maybe with the addition of team branches a core-updates branch would be much more manageable? and it'd be easier to merge it more frequently?

I think even fewer people will feel responsible for that unloved
branch. 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 would call "the farmers".

2. All team branches have to go through core-updates. That would
strike a balance between individual and project responsibility. Like
the "Three Musketeers," it would be "all for one, and one for all" at
that point. The pressure to make the branch clean will be felt from
all parts of the project. I would also rename the core-updates branch
to 'testing'.

3. When fixes do not introduce new features, like security or
documentation patches, the authors may appeal to "the farmers" for
direct adoption, thereby sidestepping 'testing'. The farmers can
delegate that work. The delegates I would call "the polishers".

4. No more pushes to core-updates (other than reversals) after the
second Wednesday of each month.

With that workflow, I think we would merge core-updates every one to
three weeks. People can revert.

Just another goofy idea from an odd fellow.

Kind regards
Felix

Re: branch master updated: gnu: eudev: Use new package style.

[Lars-Dominik Braun]

Hi,

> a less frequent drop in substitute availability on master would considerably elevate my satisfaction with guix as a user. and in my reading that is the cost that Christopher talks about here.

I was also unhappy enough to pull after the change was made, but
substitutes were not available yet. This is pretty bad if you don’t have
the local compute power (laptop) to build the entire Java bootstrap
chain. Or just imagine needing Haskell… I just ended up using `guix
pull --roll-back`, because that revision was unusable for me.

Woudn’t it make sense to create a “feature branch” for mass rebuilds
like this one (even if it’s just one package), get the substitutes
ready and then merge to master?

Cheers,
Lars

Re: branch master updated: gnu: eudev: Use new package style.

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]


Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 29.05.2023 um 20:29 +0100 schrieb Christopher Baines:
>> 1:
>> https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html#index-rebuild-scheduling-strategy
>>
>> As for reverting it, I'm somewhat indifferent. I'm more interested in
>> the longer term cost of making changes like this than the temporary
>> drops in substitute availability.
>
> You mean as a precedent for similar commits in the future or as a way
> of involuntarily breaking other packages?  As already stated, I only
> pushed the commit because I was quite sure that all rebuilds would
> succeed.

I'm more thinking of "cost" to do with capacity on the build farm. Even
though nothing should fail to build, the builds still need to happen,
and there are other builds that will be delayed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: branch master updated: gnu: eudev: Use new package style.

[Maxim Cournoyer]

Hello,

Lars-Dominik Braun <lars@6xq.net> writes:

> Hi,
>
>> a less frequent drop in substitute availability on master would
> considerably elevate my satisfaction with guix as a user. and in my
> reading that is the cost that Christopher talks about here.
>
> I was also unhappy enough to pull after the change was made, but
> substitutes were not available yet. This is pretty bad if you don’t have
> the local compute power (laptop) to build the entire Java bootstrap
> chain. Or just imagine needing Haskell… I just ended up using `guix
> pull --roll-back`, because that revision was unusable for me.
>
> Woudn’t it make sense to create a “feature branch” for mass rebuilds
> like this one (even if it’s just one package), get the substitutes
> ready and then merge to master?

I've recently wanted filling the gaps with the envisioned/proposed
team/feature-based branches workflow [0]; the result is that we can now
provide TLS certificates to team members or other people inclined to
manage the Cuirass job specifications via its web interface to select
which short-lived branches to build.

If team members would like one, message guix-sysadmin, and we can
provide you with a TLS cert for authenticating you on
https://ci.guix.gnu.org so that you can add/remove job specification
(branches) to build.

[0]  https://issues.guix.gnu.org/63375

-- 
Thanks,
Maxim