Re: guix git build error

[Andy Tai]

On Tue, Mar 7, 2023 at 10:47 PM Julien Lepiller  wrote:
> I'm afraid I'm unable to reproduce your error. You could try cleaning
> the translated texi files to make sure you get the most up-to-date ones:
>
> rm doc/*.texi
> git checkout doc
> Does that help?


This fixed it. Thanks!

Re: guix git build error

[Julien Lepiller]

Hi Andy,

I'm afraid I'm unable to reproduce your error. You could try cleaning
the translated texi files to make sure you get the most up-to-date ones:

rm doc/*.texi
git checkout doc

Does that help?

Otherwise, I'll need you to send me say guix-cookbook.fr.texi. There
shouldn't be a refernece to an English title, since it's fully
translated. Maybe the POXREF step didn't work well for you?

Le Tue, 7 Mar 2023 21:49:49 -0800,
Andy Tai  a écrit :

> Just check out origin/master of guix git HEAD,
> 
> make error:
> 
> Compiling Scheme modules...
>   GEN  etc/openrc/guix-daemon
> [  0%] LOAD guix.scm
>   GEN  etc/gnu-store.mount
>   GEN  etc/guix-daemon.service
>   GEN  etc/guix-publish.service
>   GEN  etc/guix-gc.service
>   GEN  etc/init.d/guix-daemon
> ./doc/guix-cookbook.fr.texi:652: @pxref reference to nonexistent node
> `A Scheme Crash Course'
> ./doc/guix-cookbook.fr.texi:3370: @ref reference to nonexistent node
> `Reproducible profiles'
>   GEN  etc/guix-daemon.conf
>   GEN  etc/guix-publish.conf
> make[2]: *** [Makefile:5300: doc/guix-cookbook.fr.info] Error 1
> make[2]: *** Waiting for unfinished jobs
> ./doc/guix-cookbook.sk.texi:634: @pxref reference to nonexistent node
> `A Scheme Crash Course'
> ./doc/guix-cookbook.sk.texi:3256: @ref reference to nonexistent node
> `Reproducible profiles'
> ./doc/guix-cookbook.ko.texi:624: @pxref reference to nonexistent node
> `A Scheme Crash Course'
> make[2]: *** [Makefile:5388: doc/guix-cookbook.sk.info] Error 1
> 
> 
> 
> This did not happen before (as far as what I have seen)
> 

guix git build error

[Andy Tai]

Just check out origin/master of guix git HEAD,

make error:

Compiling Scheme modules...
  GEN  etc/openrc/guix-daemon
[  0%] LOAD guix.scm
  GEN  etc/gnu-store.mount
  GEN  etc/guix-daemon.service
  GEN  etc/guix-publish.service
  GEN  etc/guix-gc.service
  GEN  etc/init.d/guix-daemon
./doc/guix-cookbook.fr.texi:652: @pxref reference to nonexistent node `A
Scheme Crash Course'
./doc/guix-cookbook.fr.texi:3370: @ref reference to nonexistent node
`Reproducible profiles'
  GEN  etc/guix-daemon.conf
  GEN  etc/guix-publish.conf
make[2]: *** [Makefile:5300: doc/guix-cookbook.fr.info] Error 1
make[2]: *** Waiting for unfinished jobs
./doc/guix-cookbook.sk.texi:634: @pxref reference to nonexistent node
`A Scheme Crash Course'
./doc/guix-cookbook.sk.texi:3256: @ref reference to nonexistent node
`Reproducible profiles'
./doc/guix-cookbook.ko.texi:624: @pxref reference to nonexistent node
`A Scheme Crash Course'
make[2]: *** [Makefile:5388: doc/guix-cookbook.sk.info] Error 1



This did not happen before (as far as what I have seen)

Re: bug#61894: [PATCH RFC] Team approval for patches

[Leo Famulari]

I don't have a strong opinion one way or the other about whether we
should formalize the review process. The status quo isn't working well,
so I'm in favor of trying something.

On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
> I think the main problem we have is social, not organizational.  There's
> little incentive to jump into the laborious review process compared to
> hack on something we like in our free time.  We need to promote and
> value review work more, without making it feel like a compulsory chore.
> That's a great challenge to solve for a project that's driven by
> volunteers.

However, I agree with this point wholeheartedly. We really need to ask
ourselves, why would anyone review patches? It's a lot of work, often
thankless, and unfortunately sometimes unpleasant.

> I'll venture a suggestion to explore: adding enticements to review (some
> playful guidelines such as "while waiting for your 2 weeks review
> period, please try to review twice as many other submissions that have
> been patiently waiting on the patches tracker :-)", or some stats
> crunched and advertised periodically to guix-devel or even our to our
> blog about our top reviewers, etc.).

In release announcements, alongside to the the normal `git shortlog`
list of authors, I suggest also publicizing the list of committers:

`git shortlog --numbered --summary --committer v1.4.0..HEAD`

A small thing, but hopefully one of many incentives to review and
commit.

Re: The package/inherit trap

[Tobias Geerinckx-Rice]

Hi,

On 7 March 2023 17:46:50 UTC, Simon Tournier  wrote:
>Well, from my point of view, we have a trap because the documentation is
>not clear. :-)

Both.

However, merely documenting something is not enough when we have the chance to 
fix misleading naming, as we do here.  It would be nice to have, but orthogonal.



Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Unique user and group names validation (was: Re: Backward incompatible changes in mpd-service-type)

[Maxim Cournoyer]

+CC guix-devel, Jonathan

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Montag, dem 06.03.2023 um 20:13 -0500 schrieb Maxim Cournoyer:
>> > Am Freitag, dem 17.02.2023 um 07:53 -0500 schrieb Maxim Cournoyer:
>> > > Else an error rather than a warning when multiple same-name users
>> > > are defined would be more appropriate, I think.
>> > Guess what, it used to be a formatted message (i.e. an actual
>> > error).  However, that broke some configs as reported in [1], so I
>> > demoted it to a warning.
>> 
>> Interesting.  I didn't know we were usefully (?) abusing duplicate
>> users and group.
> As far as I'm aware, we aren't.  Even if such uses exist, they raise
> said warning and probably cause more issues down the line, like with
> your bug report.
>
>> Perhaps we should try to isolate the most common offenders
>> (services?), fix them up, and then re-introduce the check, perhaps
>> gradually (e.g. "in 6 months time, duplicated users or groups will
>> become a configuration error").
> The only instance known to me (cups creating a duplicate lp group) was
> fixed back in 2021.

I'm starting a new discussion about it on guix-devel with the hope we
can better our understanding of which configurations would be broken if
8488f45b6e05d646224cc2b410497ddf9864c612 was re-instated, which seems
like a good idea to me?

-- 
Thanks,
Maxim

Re: guix install nyxt failure

[Simon Tournier]

Hi,

On Wed, 02 Nov 2022 at 13:33, zimoun  wrote:

> However, you report an issue with inkscape when there is no path between
> nyxt and inkscape; at least, it is what “guix graph --path nyxt
> inkscape” says.

My bad, that’s incorrect:

--8<---cut here---start->8---
$ guix graph -t bag --path nyxt -e '(@@ (gnu packages inkscape) 
inkscape/stable)'
nyxt@2.2.4
webkitgtk@2.36.8
gtk-doc@1.33.2
dblatex@0.3.12
inkscape@1.1.1
--8<---cut here---end--->8---


Cheers,
simon

Re: The package/inherit trap

[Simon Tournier]

Hi Maxim,

On Tue, 07 Mar 2023 at 11:43, Maxim Cournoyer  wrote:

>> @lisp
>> (use-modules (gnu packages gdb))   ;for 'gdb'
>>
>> (define gdb-sans-guile
>>   (package
>> (inherit gdb)
>> (inputs (modify-inputs (package-inputs gdb)
>>   (delete "guile")
>> @end lisp
>
> Do you mean inconsistent because based on what I wrote it should have
> used "package/inherit gdb ..." instead of (package (inherit gdb) ...) ?

Based on my understanding about what you wrote.

> If so, I agree.  It could be modified to use the former and an extra
> explanation offered about why package/inherit is used here when it's to
> be preferred to plain inheritance.

Well, from my point of view, we have a trap because the documentation is
not clear. :-)

Well, I think it is not only by replacing in the example.  I think the
manual should provide 2 examples and makes a clear line when one needs
to pick ’inherit’ or when one needs to pick ’package/inherit’.

Somehow, we have a similar issue as we had before with “Snippet vs
Phases“.  It would help to have plain words for ’package/inherit’ use
cases; assuming all the other use cases are covered by ’inherit’. ;-)

Cheers,
simon

Re: Feedback on indentation rules

[Simon Tournier]

Hi Maxim,

On Tue, 07 Mar 2023 at 11:54, Maxim Cournoyer  wrote:

>> For what it is worth, I do not see an high difference between the both
>> indentations.  So, my opinion would to keep the current practise.
>
> Please take a look at my original message in this thread,
> https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00297.html,
> where I gave examples of gexp->derivation indentations that should
> explain the rationale allow nesting arguments more naturally, as if
> gexp->derivation was a special form (although it's a simple procedure).

Yeah, I have read this rationale before. :-)

My question was somehow directed to Ludo:

> Yes, that’s my take and current practice so far: special rules for
> special forms (macros), not for procedures.

What is the rationale?  Being able to know directly at the location when
it is a plain function or a special form?

Sorry for having been unclear.

And I do not see a big difference between,

  (gexp->derivation "check-deb-pack"
(with-imported-modules '((guix build utils))

or

  (gexp->derivation "check-deb-pack"
(with-imported-modules '((guix build utils))

It is somehow personal cosmetic and I am sometimes poor person about
cosmetic. ;-)

Well, from my point of view, based on consistency with current
practises, I would be inclined to keep the status quo: special rule for
special form.

Cheers,
simon

Re: Merging branch wip-haskell

[Andreas Enge]

Am Wed, Feb 22, 2023 at 12:54:03PM +0200 schrieb Efraim Flashner:
> > By the way, when building pandoc for my core-updates profile, I noticed
> > that ghc bootstrapping takes a terribly long time. Might there be a fleeting
> > chance to jump over some older releases?
> I believe in core-updates I've changed it so we go from 8.6 to 8.10. I
> think if we packaged 8.2 we could go from 7.10 -> 8.2 -> 8.6 -> 8.10,
> using 8.2 to replace 8.0 and 8.4.

Good to hear that! Right now I indeed see the following:
7.10.3, 8.0.2, 8.4.4, 8.6.5, 8.10.7, 9.2.5.
There is also a 9.0 (which could be dropped maybe?), but 9.2 is built
from 8.10. And 8.10 is built with 8.6, but inherits from 8.8; to make
things simpler, it would be nice to drop 8.8, but this would imply some
work to get the right differences between the recipe for 8.6 and for 8.10.

Andreas

Re: bug#61894: [PATCH RFC] Team approval for patches

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

> Hi,
>
> On Tue, 07 Mar 2023 at 11:36, Andreas Enge  wrote:
>
>> 1) Every current and potential new package is covered by a team.
>> 2) Every team has at least 3 members, better yet 4 or 5.
>>3 members would make it possible that even if one of them is on vacation
>>or otherwise busy a patch could be pushed without this additional one
>>week if the other 2 agree.
>
> It would help if being committer implies appearing at least in one team,
> no?
>
> Currently in etc/teams.scm.in, I count 26 members and 20 are committers
> over the 48 ones.  No blame. :-)

If most committers end up being team members, aren't we back to where we
currently stand?  It seems the original motivation here is to add some
extra control/guards against undesirable commits landing in the core of
Guix.  If a committer that previously landed such commits joined the
core team (e.g., myself), it seems to me the situation would be little
changed:

1. Our pool of reviewers would likely continue to be spread too thin.

2. The 2 weeks time window would quickly slip, even with a team looking
at a more focused backlog, or the reviews would only be of the kind "I
think that's not what we want" without more time or energy to offer the
kind of concrete insights that can be turned into action for the
submitter.

3. The team member might be tempted to take their chance and merge their
change with little to no feedback, or feedback they perceived
insufficient or not actionable enough to justify keeping their
submission in limbo for longer.

I think the main problem we have is social, not organizational.  There's
little incentive to jump into the laborious review process compared to
hack on something we like in our free time.  We need to promote and
value review work more, without making it feel like a compulsory chore.
That's a great challenge to solve for a project that's driven by
volunteers.

I'll venture a suggestion to explore: adding enticements to review (some
playful guidelines such as "while waiting for your 2 weeks review
period, please try to review twice as many other submissions that have
been patiently waiting on the patches tracker :-)", or some stats
crunched and advertised periodically to guix-devel or even our to our
blog about our top reviewers, etc.).

-- 
Maxim

[Internship] Fwd: [gnu-soc] [IMPORTANT] Mentors please ask for an invitation into the org

[Gábor Boskovits]

Hello guix,

The following information was sent to the summer of code list, and hereby I
forward it to the list,
as it contains information for prospective mentors:

-- Forwarded message -
Feladó: Jose E. Marchesi 
Date: 2023. márc. 4., Szo, 17:32
Subject: [gnu-soc] [IMPORTANT] Mentors please ask for an invitation into
the org
To: 



Hello people.

We need to add the different prospective mentors in the GNU organization
in the GSOC website [1].

For that, we need an email address that we can use to issue an
invitation.

Regardless of whether the mentor eventually mentors a contributor or
not, we need to fill them in the system.

So please send me an email, either privately or in the list, specifying
the email addresses of the mentors so I can add them in the system.

Thanks!

So, people willing to mentor on this round GSoC please contact Jose.

Thanks.

Regards,
g_bor

Re: Ungoogled-chromium in core-updates

[Leo Famulari]

On Tue, Mar 07, 2023 at 06:14:46PM +0100, Andreas Enge wrote:
> Ah, this is a crazy program - C++!
> It just failed after 17h of compilation in the very last step:
> [52515/52515] LINK ./chrome
> FAILED: chrome
> since I had only 51 GB of free space on my disk...
> 
> Otherwise said, I expect it to still build, but will not try it again
> myself :)

Haha! Yes, I think you can count this as a success :)

Re: Ungoogled-chromium in core-updates

[Andreas Enge]

Am Sat, Feb 25, 2023 at 03:41:58PM +0100 schrieb Andreas Enge:
> Ungoogled-chromium compiles on core-updates! I now even tried it out
> and it shows a website :)

Ah, this is a crazy program - C++!
It just failed after 17h of compilation in the very last step:
[52515/52515] LINK ./chrome
FAILED: chrome
since I had only 51 GB of free space on my disk...

Otherwise said, I expect it to still build, but will not try it again
myself :)

Andreas

Re: Feedback on indentation rules

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

> Hi,
>
> On Mon, 06 Mar 2023 at 17:56, Ludovic Courtès  wrote:
>> Maxim Cournoyer  skribis:
>>
>>> Thanks for the feedback.  I wonder if some are of the opinion that since
>>> gexp->derivation is a plain function rather than a syntax having a
>>> special form for its 2nd argument, we should leave the default
>>> indentation rules untouched for it?
>>
>> Yes, that’s my take and current practice so far: special rules for
>> special forms (macros), not for procedures.
>
> What is the rationale?  Being able to know directly at the location when
> it is a plain function or a special form?
>
> For what it is worth, I do not see an high difference between the both
> indentations.  So, my opinion would to keep the current practise.

Please take a look at my original message in this thread,
https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00297.html,
where I gave examples of gexp->derivation indentations that should
explain the rationale allow nesting arguments more naturally, as if
gexp->derivation was a special form (although it's a simple procedure).

-- 
Thanks,
Maxim

Re: The package/inherit trap

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

> Hi,
>
> On Fri, 03 Mar 2023 at 20:21, Tobias Geerinckx-Rice  wrote:
>
>> Could we rename it to something like 
>> ‘package+replacements/inherit’?  To me, that captures the spirit, 
>> without being overly longer.
>
> Well, I gave a look at the code and have seen the replacement.  But I
> had not thought about the package transformation and the like.
>
> From my point of view, the best would to add a paragraph with index
> entries under “Defining-Package-Variants” section [1].
>
> However, in the light of Maxim’s explanations, the example from the
> manual appears to me inconsistent:
>
> You can just as well define variants with a different set of
> dependencies than the original package.  For example, the default
> @code{gdb} package depends on @code{guile}, but since that is an
> optional dependency, you can define a variant that removes that
> dependency like so:
>
> @lisp
> (use-modules (gnu packages gdb))   ;for 'gdb'
>
> (define gdb-sans-guile
>   (package
> (inherit gdb)
> (inputs (modify-inputs (package-inputs gdb)
>   (delete "guile")
> @end lisp

Do you mean inconsistent because based on what I wrote it should have
used "package/inherit gdb ..." instead of (package (inherit gdb) ...) ?
If so, I agree.  It could be modified to use the former and an extra
explanation offered about why package/inherit is used here when it's to
be preferred to plain inheritance.

-- 
Thanks,
Maxim

Re: bug#61894: [PATCH RFC] Team approval for patches

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Tue, Mar 7, 2023 at 2:37 AM Andreas Enge  wrote:
>
> And the feature branches with
> QA on cuirass or the Guix Build Coordinator that we talked about at the
> Guix Days.

For what it's worth, someone turned one of my patch sets into a
proof-of-concept for feature branches. You can follow the progress via
the original patch, [1] the feature branch, [2] or the resulting CI
job set. [3]

[1] https://issues.guix.gnu.org/61989
[2] https://qa.guix.gnu.org/issue/61989
[3] https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-go-updates

> There are currently 48 committers, and not all of them are active.
> I think this is just not enough for 2 packages.

If a brief comparison is permitted, Debian maintains 35,000 source
packages with about a thousand voting members (aka Debian Developers)
as well as another thousand or so contributors. My estimate is that
about a third of all those people are active. On a per-package basis,
that's about fifty source packages per contributor there.

For Guix, I do not know how many committers are active or how many
people contribute without commit privileges, but assuming two hundred
active contributors altogether, I arrive at a guesstimate of about 100
packages per contributor for us.

Packaging in Guix is much simpler, however, and our collective
approach and care also reduce the pressure to be perfect. (In Guix,
the "perfect" sentiment only survives in the formattin of commit
messages.) Debian's celebrity status among software distributions also
attracts a lot of people.

As a side note, the growth of a group can lead to greater social
tensions and a proliferation of outside politics. Given the excellent
stewardship in Guix to date and the technical possibilities of
automatic patch approval, I am therefore not necessarily in favor of
growing the contributor base at all costs.

We really have something special in Guix. Thank you all for your hard
work and mutual friendship!

Kind regards,
Felix Lechner

Re: bug#61894: [PATCH RFC] Team approval for patches

[Simon Tournier]

Hi,

On Tue, 07 Mar 2023 at 11:36, Andreas Enge  wrote:

> 1) Every current and potential new package is covered by a team.
> 2) Every team has at least 3 members, better yet 4 or 5.
>3 members would make it possible that even if one of them is on vacation
>or otherwise busy a patch could be pushed without this additional one
>week if the other 2 agree.

It would help if being committer implies appearing at least in one team,
no?

Currently in etc/teams.scm.in, I count 26 members and 20 are committers
over the 48 ones.  No blame. :-)

Somehow, we have a bootstrap problem – bootstrap is everywhere. ;-)

>From my understanding, Ludo’s proposal is about some structure of how
“teams“ would work and that structure would help in constituting
“teams”.  One way for bootstrapping.

>From my understanding, the other approach somehow proposed between the
lines in this thread would be to first constitute “teams” and then
document how they work.  The other way for bootstrapping.

While I am not convinced by Ludo’s patch, I think the approach to
document first how we would like the “teams” would work is better for
bootstrapping them.

Cheers,
simon

Re: Feedback on indentation rules

[Simon Tournier]

Hi,

On Mon, 06 Mar 2023 at 17:56, Ludovic Courtès  wrote:
> Maxim Cournoyer  skribis:
>
>> Thanks for the feedback.  I wonder if some are of the opinion that since
>> gexp->derivation is a plain function rather than a syntax having a
>> special form for its 2nd argument, we should leave the default
>> indentation rules untouched for it?
>
> Yes, that’s my take and current practice so far: special rules for
> special forms (macros), not for procedures.

What is the rationale?  Being able to know directly at the location when
it is a plain function or a special form?

For what it is worth, I do not see an high difference between the both
indentations.  So, my opinion would to keep the current practise.


Cheers,
simon

Re: Follow-up on julia import script

[Simon Tournier]

Hi Nicolas,

On Mon, 06 Mar 2023 at 12:23, Nicolas Graves wrote:

> I have a WIP version which should solve the issues of hash and
> native-inputs.

Awesome!


> I still have the two following issues, if someone has a hint:
>
>> - there's a difficulty for defining guix-name->julia-name with the
>>   simple guix/import/utils.scm snake-case. We should define proper
>>   functions to convert without ambiguity from CamelCase to snake-case
>>   and back, and that also encompasses cases like JuMP and OCReract. I
>>   had one option in mind but haven't tested it to get the name in the
>>   url. Or maybe we should have a #:julia-name field in arguments or
>>   properties. WDYT ?

I suggest to track the upstream name with the field ’properties’, e.g.,

(properties `((upstream-name . "CamelCase")))

as it is done for CRAN/Bioconductor importer; see (guix import cran).


>> - readme is full of html junk, I don't know if we can process it to get
>>   pure text output easily in Guile ?

Yeah, I do not know either.

Cheers,
simon

Re: intrinsic vs extrinsic identifier: toward more robustness?

[Simon Tournier]

Hi,

On Mon, 06 Mar 2023 at 13:22, Maxime Devos  wrote:

>>> For git-fetch, the value of the 'commit' field is intrinsic (except when
>>> it's a tag instead).
>> 
>> No, it is imprecise.  The exception is *not* label tag as value for the
>> ’commit’ field but the exception is Git commit hash as value.
>
> Are you referring to the fact that currently, the 'commit' field usually 
> contains a tag name, and that it containing a commit is the exception?

Yes.

> If so, that doesn't contradict my claim.

There is no contradiction but imprecision.


> I do not see how making a list of all identifiers helps with robustness 
> -- you need the object the identifiers point to, not the identifier itself.

If you have the identifiers, you have a chance to find again the
content.  For example, in addition to NAR+SHA256, we could also store
Git+SHA1 or plain SHA256 or something else.  It would help in exploiting
other content-address systems.  For instance, SWH stores,

"checksums": {
"sha1": "3a48fbd0a69c7875dc18bd48a16da04d1512ed47",
"sha1_git": "69cb76019a474330e99666f147ecb85e44de1ce6",
"sha256": 
"e62e0f13f9025642a52f9fcb12ca0c31d5e05f78e97224f55b3d70d47c73b549"
},

and maybe ’sha256_nar’ soon.  Somehow, we have a list of mirrors so why
not similarly having a list of intrinsic identifier.


> You are hashing the 'hello-2.12.1' directory

Thanks!  Having the noise too close and I missed the obvious. :-)


Cheers,
simon

Re: The package/inherit trap (was: gnu: stellarium: Enable ShowMySky.)

[Simon Tournier]

Hi,

On Fri, 03 Mar 2023 at 20:21, Tobias Geerinckx-Rice  wrote:

> Could we rename it to something like 
> ‘package+replacements/inherit’?  To me, that captures the spirit, 
> without being overly longer.

Well, I gave a look at the code and have seen the replacement.  But I
had not thought about the package transformation and the like.

>From my point of view, the best would to add a paragraph with index
entries under “Defining-Package-Variants” section [1].

However, in the light of Maxim’s explanations, the example from the
manual appears to me inconsistent:

--8<---cut here---start->8---
You can just as well define variants with a different set of
dependencies than the original package.  For example, the default
@code{gdb} package depends on @code{guile}, but since that is an
optional dependency, you can define a variant that removes that
dependency like so:

@lisp
(use-modules (gnu packages gdb))   ;for 'gdb'

(define gdb-sans-guile
  (package
(inherit gdb)
(inputs (modify-inputs (package-inputs gdb)
  (delete "guile")
@end lisp
--8<---cut here---end--->8---

Well, since the trap is not completely clear for me yet, I am not able
to propose a paragraph.  IMHO, a paragraph here would help in mitigating
the trap.  Whatever the name of ’package/inherit’. :-)

1: 


Cheers,
simon

Re: bug#61894: [PATCH RFC] Team approval for patches

[Andreas Enge]

Hello,

Am Tue, Mar 07, 2023 at 09:53:29AM +0800 schrieb 宋文武:
> I usually push patches for others who don't have commit access, while
> most packages don't have a team at all, and some with me as the only
> team member.
> Should I wait for another commiter's approvol under this new policy or
> can I push "random packages" (eg: jwm) solo under the status quo?  For
> packages I as the only team member (eg: fcitx), should I looking for
> another commiter for other's patches and my patches?

under the current policy, what you do is fine and very welcome. Under the
new policy, it would not be (if I remember correctly, there is a one week
waiting policy, after which one could push nevertheless).

So while the idea is good in principle, I think we would have to make sure
that first:
1) Every current and potential new package is covered by a team.
2) Every team has at least 3 members, better yet 4 or 5.
   3 members would make it possible that even if one of them is on vacation
   or otherwise busy a patch could be pushed without this additional one
   week if the other 2 agree.

And I also think we then need 3) more tooling; maybe a mailing list for each
team? A file that contains the link between source code files and teams,
and a script around "git send-email" that automatically puts into cc the
corresponding team when submitting a patch? And the feature branches with
QA on cuirass or the Guix Build Coordinator that we talked about at the
Guix Days.

I think our main problem right now is lack of committers and/or contributors.
While looking at core-updates, I was surprised how outdated some of our
packages are (around Qt, KDE and Python, for instance; I suppose it depends
a lot on the field), in particular for a rolling release distro. (For Qt@5,
we were at a release from June 2022, and there had been more recent
releases in September, October and January; it would be nice to have a
working team preparing a feature branch in a timely fashion after each
release.)

There are currently 48 committers, and not all of them are active.
I think this is just not enough for 2 packages.

Andreas

Re: Guix v1.1.0 (~2020) and Software Heritage & friends

[Simon Tournier]

Hi Ludo,

Thanks for giving a look and for your insights.

On Mon, 6 Mar 2023 at 21:40, Ludovic Courtès  wrote:

> Maybe we should write down a road map and “recruit” on these items?

Yeah, I totally agree. :-)  For what it is worth, in that mood, for instance,

 + GSoC 
 + Patch #62008 
 + SWH #4538< https://gitlab.softwareheritage.org/swh/meta/-/issues/4538>

Well, I will try to summarize the current status of Disarchive.

Cheers,
simon