Displaying modules load depth to hunt cycles (or just for fun)
Hi Guix!
I've recently hacked a bit on Guile to try to make the output when using
(set! %load-verbosely #t) in e.g. (guix config) more helpful; giving it
a second dimension (the depth at which modules are loaded). It works,
but the default %load-hook needs to be refined as it uses too much
screen width.
To test it, I've done something like:
1. Build Guile with changes from
https://notabug.org/apteryx/guile/src/load-verbosely-show-depth.
2. configure Guix checkout to use it, e.g.:
./configure --localstatedir=/var --sysconfdir=/etc
GUILE=/home/maxim/src/guile/meta/guile
3. Override the guix local 'guile' copy:
--8<---cut here---start->8---
guix $ mv guile{,.bak}
guix $ ln -s ln -s /home/maxim/src/guile/meta/guile guile
--8<---cut here---end--->8---
4. Apply a problematic change that introduce a circular dependency at
the module level (from #65718):
--8<---cut here---start->8---
modified gnu/packages/firmware.scm
@@ -43,6 +43,7 @@ (define-module (gnu packages firmware)
#:use-module (gnu packages admin)
#:use-module (gnu packages autotools)
#:use-module (gnu packages assembly)
+ #:use-module (gnu packages avr)
#:use-module (gnu packages backup)
#:use-module (gnu packages base)
#:use-module (gnu packages bash)
--8<---cut here---end--->8---
4. Run: ./pre-inst-env guix build hello to see the result:
--8<---cut here---start->8---
$ ./pre-inst-env guix build hello
;;; note: source file /home/maxim/src/guix/guix/config.scm
;;; newer than compiled /home/maxim/src/guix/guix/config.go
;;; note: source file /home/maxim/src/guix/guix/config.scm
;;; newer than compiled
/run/current-system/profile/lib/guile/3.0/site-ccache/guix/config.go
;;; loading /home/maxim/src/guile/module/srfi/srfi-71.scm
;;; loading /home/maxim/src/guile/module/rnrs/io/ports.scm
;;; loading /home/maxim/src/guile/module/ice-9/binary-ports.scm
;;; loading /home/maxim/src/guile/module/ice-9/custom-ports.scm
;;; loading /home/maxim/src/guile/module/ice-9/textual-ports.scm
;;; loading /home/maxim/src/guile/module/ice-9/rdelim.scm
;;; loading
/home/maxim/src/guile/module/rnrs/bytevectors/gnu.scm
;;; loading /home/maxim/src/guile/module/rnrs/base.scm
;;; loading /home/maxim/src/guile/module/ice-9/iconv.scm
;;; loading /home/maxim/src/guile/module/rnrs/enums.scm
;;; loading /home/maxim/src/guile/module/rnrs/conditions.scm
;;; loading /home/maxim/src/guile/module/rnrs/exceptions.scm
;;; loading /home/maxim/src/guile/module/rnrs/control.scm
;;; loading /home/maxim/src/guile/module/rnrs/records/procedural.scm
;;; loading /home/maxim/src/guile/module/rnrs/syntax-case.scm
;;; loading /home/maxim/src/guile/module/ice-9/optargs.scm
;;; loading /home/maxim/src/guile/module/system/base/pmatch.scm
;;; loading /home/maxim/src/guile/module/rnrs/records/syntactic.scm
;;; loading /home/maxim/src/guile/module/rnrs/hashtables.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-69.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-13.scm
;;; loading /home/maxim/src/guile/module/rnrs/lists.scm
;;; loading /home/maxim/src/guile/module/rnrs/files.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-8.scm
;;; loading /home/maxim/src/guile/module/ice-9/receive.scm
;;; loading /home/maxim/src/guix/guix/build/utils.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-34.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-60.scm
;;; loading /home/maxim/src/guile/module/ice-9/ftw.scm
;;; loading /home/maxim/src/guile/module/ice-9/vlist.scm
;;; loading /home/maxim/src/guix/guix/build/syscalls.scm
;;; loading /home/maxim/src/guile/module/system/foreign.scm
;;; loading /home/maxim/src/guile/module/system/base/target.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-19.scm
;;; loading /home/maxim/src/guile/module/srfi/srfi-6.scm
;;; loading /home/maxim/src/guile/module/ice-9/i18n.scm
;;; loading /home/maxim/src/guile/module/system/foreign-library.scm
;;; loading /home/maxim/src/guix/guix/combinators.scm
;;; loading /home/maxim/src/guix/guix/deprecation.scm
;;; loading /home/maxim/src/guix/guix/serialization.scm
;;; loading /home/maxim/src/guix/guix/monads.scm
;;; loading /home/maxim/src/guile/module/system/syntax.scm
;;; loading /home/maxim/src/guix/guix/records.scm
;;; loading /home/maxim/src/guix/guix/base16.scm
;;; loading /home/maxim/src/guix/guix/base32.scm
;;; loading
Re: How can we decrease the cognitive overhead for contributors?
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 commits for the effective > > > diff, but in my role as a reviewer I usually rebase, squash, and > > > merge. > > > > > > This workflow is more familiar to some and alienating to others, > > > but both of these workflows would work fine for Guix. But today > > > our tools can only accommodate *one* workflow. > > I'd imagine that rebase, squash and merge would exacerbate the > > workload on the committer side and I think that most popular > > projects on those forges already experience similar effects to us > > despite folks just merging the requests as-is and in part even > > getting paid by big tech for doing so. > > Look, I’m relating merely my work experience here as someone who > regularly reviews pull requests on Github. Github has buttons for > “Rebase and merge”, “Squash and merge”, and “Create a merge commit”, > so that part is automated. > > I’m not saying that this is the workflow we should adopt. I’m saying > that these platforms — for better or worse — encourage *different* > workflows, and for some this is what they are most comfortable with. How many different workflows are those? In my opinion, the one that folks typically refer to when mentioning comfort is 1. git branch 2. git push elsewhere [ long conversation using the forge's blessed UI ] ?. git merge Fair enough, as a committer you get the option of cherry-picking, rebasing, or whatever else instead of a merge, but the UI support for those alternatives ranges from "okay, I guess" to "you know how to do this by command line, don't you?" and "this change will be marked as rejected even though you actually merged it". Whenever you're using these platforms, you are being nudged into its happy path, just as the contribution via email model really makes it hard to just type "git merge" and expect success – you do need git am at some point. > 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. > Recall that the reason for my response at this point in the thread is > your statement: > > > Hiding obsolete versions of a pull request is in practice > > implemented either by pushing more commits on top of the existing > > one, often with dubious commit messages or by force-pushing a > > branch, neither of which is an acceptable solution for Guix. > > I’m trying to convey that this workflow is similar to how we would > push to wip-* branches and informally discuss open issues out of > band. (And even in that scenario, we are rather limited by the way > our shared repository with all-or-nothing permission management > works.) I think this is a bit of an apples to oranges comparison. Even for our wip branches, we mostly adhere to the guidelines that govern master, it's mostly the rule regarding breaking changes that is relaxed. We wouldn't have well-functioning wip branches if those forewent *all* communication efforts. The only common ground I can see is that all feature branches – or at least those that don't die – get merged to the main branch in either workflow. Cheers
Re: How can we decrease the cognitive overhead for contributors?
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 have tests for the search feature there. I would like to, but I'm experiencing some trouble getting the data. How do you populate the mocked spool?
Re: Cadence For Merging python-team into master
Thanks, I'll take a look once I find the time to look into sphinx failures. best, jgart
Re: How can we decrease the cognitive overhead for contributors?
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 summary of the >> changes before pushing or sending them off for review. But at least >> I don’t have to write them myself. >> >> 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 >> people that I’ve mentored. >> >> etc/committer.scm and the yasnippets are supposed to alleviate some >> of the pain, but I don’t need to think for a long time to come up >> with a number of improvements in this area. > Can I assume this to mean it'd take you some short time to think of > snippets that we're currently lacking? If so, please do contribute > them. If not, what do you mean then? I mean that they have plenty of defects. When I wrote the first few iterations of etc/committer.scm it was only really meant and good for bulk package updates (= lots of changes across files, all upgrades). It couldn’t (and maybe still can’t) reliably detect added or removed package definitions. It doesn’t handle changes to the arguments field. It’s also terribly slow because it naively recomputes information for every hunk in the diff, reading package definitions from the old vs the changed file after every commit. The update yasnippet repeatedly gets the order of lines wrong when adding a patch to dist_patch_DATA in gnu/local.mk; it also doesn’t do what etc/committer.scm is already able to do: detecting changes to inputs. Configuring yasnippet is also not trivial for people who don’t regularly use Emacs (the snippets are tied to modes set by magit). I think in light of these defects “Uhm, we have snippets?” isn’t a satisfying response. -- Ricardo
Re: guix build from git failure: missing sections in German, French, etc. doc translations？
On 2023-09-08 21:26:56 +0200, Julien Lepiller wrote: > Hi Andy, > > Thanks for the report! You might need a more recent po4a for it to work > properly. Could try to guix pull, and enter a new shell for building guix? > > Le 8 septembre 2023 20:43:05 GMT+02:00, Andy Tai a écrit : > >Checking out the latest origin/master head, building guix fails: > > > >make[2]: Entering directory '/share/software/guix/guix.git/po/packages' > >make[2]: Nothing to be done for 'all'. > >make[2]: Leaving directory '/share/software/guix/guix.git/po/packages' > >make[2]: Entering directory '/share/software/guix/guix.git' > > MAKEINFO doc/guix.info > > MAKEINFO doc/guix.de.info > > MAKEINFO doc/guix.fr.info > > MAKEINFO doc/guix.es.info > > MAKEINFO doc/guix.pt_BR.info > >contributing.pt_BR.texi:1338: @menu reference to nonexistent node > >`Configuring Git' > >contributing.pt_BR.texi:1339: @menu reference to nonexistent node > >`Sending a Patch Series' > >contributing.de.texi:1447: @menu reference to nonexistent node `Configuring > >Git' > >contributing.de.texi:1448: @menu reference to nonexistent node > >`Sending a Patch Series' > >contributing.fr.texi:1389: @menu reference to nonexistent node `Configuring > >Git' > >contributing.fr.texi:1390: @menu reference to nonexistent node > >`Sending a Patch Series' > >make[2]: *** [Makefile:4969: doc/guix.de.info] Error 1 > >make[2]: *** Waiting for unfinished jobs > >make[2]: *** [Makefile:5099: doc/guix.fr.info] Error 1 > >make[2]: *** [Makefile:5164: doc/guix.pt_BR.info] Error 1 > > > > > >the script I used to build guix from git is attached > FWIW I did run into the same problem this morning and can confirm, guix pull does resolve the issue. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
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, squash, and merge. >> >> This workflow is more familiar to some and alienating to others, but >> both of these workflows would work fine for Guix. But today our >> tools can only accommodate *one* workflow. > I'd imagine that rebase, squash and merge would exacerbate the workload > on the committer side and I think that most popular projects on those > forges already experience similar effects to us despite folks just > merging the requests as-is and in part even getting paid by big tech > for doing so. Look, I’m relating merely my work experience here as someone who regularly reviews pull requests on Github. Github has buttons for “Rebase and merge”, “Squash and merge”, and “Create a merge commit”, so that part is automated. I’m not saying that this is the workflow we should adopt. I’m saying that these platforms — for better or worse — encourage *different* workflows, and for some this is what they are most comfortable with. 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? Recall that the reason for my response at this point in the thread is your statement: > Hiding obsolete versions of a > pull request is in practice implemented either by pushing more commits > on top of the existing one, often with dubious commit messages or by > force-pushing a branch, neither of which is an acceptable solution for > Guix. I’m trying to convey that this workflow is similar to how we would push to wip-* branches and informally discuss open issues out of band. (And even in that scenario, we are rather limited by the way our shared repository with all-or-nothing permission management works.) -- Ricardo
Re: guix build from git failure: missing sections in German, French, etc. doc translations？
Hi Andy, Thanks for the report! You might need a more recent po4a for it to work properly. Could try to guix pull, and enter a new shell for building guix? Le 8 septembre 2023 20:43:05 GMT+02:00, Andy Tai a écrit : >Checking out the latest origin/master head, building guix fails: > >make[2]: Entering directory '/share/software/guix/guix.git/po/packages' >make[2]: Nothing to be done for 'all'. >make[2]: Leaving directory '/share/software/guix/guix.git/po/packages' >make[2]: Entering directory '/share/software/guix/guix.git' > MAKEINFO doc/guix.info > MAKEINFO doc/guix.de.info > MAKEINFO doc/guix.fr.info > MAKEINFO doc/guix.es.info > MAKEINFO doc/guix.pt_BR.info >contributing.pt_BR.texi:1338: @menu reference to nonexistent node >`Configuring Git' >contributing.pt_BR.texi:1339: @menu reference to nonexistent node >`Sending a Patch Series' >contributing.de.texi:1447: @menu reference to nonexistent node `Configuring >Git' >contributing.de.texi:1448: @menu reference to nonexistent node >`Sending a Patch Series' >contributing.fr.texi:1389: @menu reference to nonexistent node `Configuring >Git' >contributing.fr.texi:1390: @menu reference to nonexistent node >`Sending a Patch Series' >make[2]: *** [Makefile:4969: doc/guix.de.info] Error 1 >make[2]: *** Waiting for unfinished jobs >make[2]: *** [Makefile:5099: doc/guix.fr.info] Error 1 >make[2]: *** [Makefile:5164: doc/guix.pt_BR.info] Error 1 > > >the script I used to build guix from git is attached
Re: How can we decrease the cognitive overhead for contributors?
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 or sending them off for review. But at least > I don’t have to write them myself. > > 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 > people that I’ve mentored. > > etc/committer.scm and the yasnippets are supposed to alleviate some > of the pain, but I don’t need to think for a long time to come up > with a number of improvements in this area. Can I assume this to mean it'd take you some short time to think of snippets that we're currently lacking? If so, please do contribute them. If not, what do you mean then? Cheers
Re: How can we decrease the cognitive overhead for contributors?
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, but the fact that new commits are pushed on top of the > branch is not an obstacle in practice, because the commits don’t > matter. > > (I know, it hurts me too, but I don’t make the rules, okay?) Well, thanks to Guix inventing the time machine, individual commits do matter to us. > And in these review interfaces we can mark individual comments as > resolved. So the flat list of changes with annotations *does* in > fact provide a clearer organization than a tree of emails. > > Note also that we don’t usually review commits by starting one new > thread for each issue we address, so we don’t benefit from automatic > branching of sub-discussions. To be fair, the summarizing of changes followed by comments to individual bits are a point that the forges at least get right. However, unless you rework a single line multiple times – which admittedly happens more often in the "push the change on top" model of the forges than in the "condense your changes to logical units" model we use – a branching discussion per commit still comes quite close in practice. Also, when there are multiple reviewers notice different things, you also get the branching tree. > 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, squash, and merge. > > This workflow is more familiar to some and alienating to others, but > both of these workflows would work fine for Guix. But today our > tools can only accommodate *one* workflow. I'd imagine that rebase, squash and merge would exacerbate the workload on the committer side and I think that most popular projects on those forges already experience similar effects to us despite folks just merging the requests as-is and in part even getting paid by big tech for doing so. (Perhaps I exaggerate at getting paid for processing merge requests, I haven't worked for any of these companies, but especially at the ones more oriented towards doing business, I'd imagine that you can at least buy yourself a sandwich from the work you do from time to time.) > It happens to be the one I’m used to, but let’s please not pretend > that it’s inherently *better* than the other. I mean, when we say better, we would have to refer to some metric of goodness. And the metric I personally choose is somewhere in the intersection of accessibility and interoperability, because that is what matters to me. With Github, Gitlab and whatever other forges you have, you are more or less bound to their web interface. If that works for you, it works. If it doesn't, it doesn't. With the email-based workflow, I can use whichever tools I am comfortable with, as long as they work for sending mail (as a contributor) or eventually invoke `git push' on a bunch of signed-off commits (as a committer). This both increases the chances of things working and gives me the tools to build things that work for myself (and potentially others as well). Cheers
guix build from git failure: missing sections in German, French, etc. doc translations？
Checking out the latest origin/master head, building guix fails: make[2]: Entering directory '/share/software/guix/guix.git/po/packages' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/share/software/guix/guix.git/po/packages' make[2]: Entering directory '/share/software/guix/guix.git' MAKEINFO doc/guix.info MAKEINFO doc/guix.de.info MAKEINFO doc/guix.fr.info MAKEINFO doc/guix.es.info MAKEINFO doc/guix.pt_BR.info contributing.pt_BR.texi:1338: @menu reference to nonexistent node `Configuring Git' contributing.pt_BR.texi:1339: @menu reference to nonexistent node `Sending a Patch Series' contributing.de.texi:1447: @menu reference to nonexistent node `Configuring Git' contributing.de.texi:1448: @menu reference to nonexistent node `Sending a Patch Series' contributing.fr.texi:1389: @menu reference to nonexistent node `Configuring Git' contributing.fr.texi:1390: @menu reference to nonexistent node `Sending a Patch Series' make[2]: *** [Makefile:4969: doc/guix.de.info] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [Makefile:5099: doc/guix.fr.info] Error 1 make[2]: *** [Makefile:5164: doc/guix.pt_BR.info] Error 1 the script I used to build guix from git is attached guix_git_build.sh Description: application/shellscript
Re: How can we decrease the cognitive overhead for contributors?
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 (Guile
> with gexp) could be rewrote as:
>
> * relative-path-of-changed-file (variable) [field] :
> Description of change.
>
> I never saw a {4th level} so AFAIU is not needed, unless someone have
> a good example plz: in this case we could add a 4th level to the
> general description.
I have seen four levels in the wild. They aren't particularly large in
population, but then again, the third level isn't needed in most cases
either. I think we should start out with (variable)[field] as the one
that covers most changes.
Btw. on the extra spaces, is there any consensus on whether to put them
there or leave them out? My personal style always leaves them out.
Anyway, looking forward to seeing your series.
Cheers
Re: How can we decrease the cognitive overhead for contributors?
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. [...] > but the effort to go through and see which packages are ACTUALLY > needed and to clean up everything, it's just too much for me. Do you find that it's too much due to the Guix ChangeLog guidelines? [...] > As far as commit messages, I've found that the script in > etc/committer.scm to be very nice, even if there are plenty of cases > where it doesn't do the job. I do think there's room for improvement > and that may be one of the things we can do to make contributing > easier. What do you propose should be changed in the commit messages guidelines to make contributing easier? In Messege-Id 87y1hhdnzj@xelera.eu today I tried to make some actionable proposals considering the contant of this thread: WDYT? Thanks, Gio' [...] -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)
Giovanni Biscuolo writes: > […] actually Debbugs or Mumi web > interfaces are read-only: you cannot open a bug report or comment it, > you have to send an email; this is a _feature_, not a bug since we don't > need a _complex_ web based authentication+authorization system for bug > reporters/commenters. […] Mumi actually does support commenting on the web: https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/web/controller.scm#n145 It’s just been disabled because messages ended up being stuck in the queue and nobody could make enough time to debug this. -- Ricardo
Re: Cadence For Merging python-team into master
"jgart" writes: > What is the cadence for merging the python-team branch into master? > > Should you do it, me, or someone else? Another thing that needs fixing is sphinx. The upgrade of python-pygments and python-sphinx did not go over too well. -- Ricardo
Re: How can we decrease the cognitive overhead for contributors?
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
Re: How can we decrease the cognitive overhead for contributors?
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 commit, or something I did > and forgot about in the early development, that should be dropped. 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 or sending them off for review. But at least I don’t have to write them myself. 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 people that I’ve mentored. etc/committer.scm and the yasnippets are supposed to alleviate some of the pain, but I don’t need to think for a long time to come up with a number of improvements in this area. > There's also no stopping you adding a more conventional rationale as a > paragraph between the topic and the ChangeLog content (which should > appear at the bottom of the commit message). Yes, this is something that might not be clear to all. Before the somewhat mechanical summary you can write a paragraph or two to give context. -- Ricardo
Re: How can we decrease the cognitive overhead for contributors?
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 hidden >> until needed (rarely). the email based model is just a flat list of >> messages that includes all the past mistakes, and the by now >> irrelevant versions. > What the? If anything, emails are like a tree and discussions in most > forges are a single long list that's rarely well organized. Virtually > every mail client supports threads, whereas a certain one of the more > popular forges still refuses to do so. Hiding obsolete versions of a > pull request is in practice implemented either by pushing more commits > on top of the existing one, often with dubious commit messages or by > force-pushing a branch, neither of which is an acceptable solution for > Guix. 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, but the fact that new commits are pushed on top of the branch is not an obstacle in practice, because the commits don’t matter. (I know, it hurts me too, but I don’t make the rules, okay?) And in these review interfaces we can mark individual comments as resolved. So the flat list of changes with annotations *does* in fact provide a clearer organization than a tree of emails. Note also that we don’t usually review commits by starting one new thread for each issue we address, so we don’t benefit from automatic branching of sub-discussions. 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, squash, and merge. This workflow is more familiar to some and alienating to others, but both of these workflows would work fine for Guix. But today our tools can only accommodate *one* workflow. It happens to be the one I’m used to, but let’s please not pretend that it’s inherently *better* than the other. -- Ricardo FWIW: Mumi is the worst of both worlds as it flattens the email tree while not providing any of the review features that popular forges have. So the problem of outdated and repeated mistakes in a flat list becomes more pronounced there.
Re: How can we decrease the cognitive overhead for contributors?
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 exactly it. I’m a parent working a full-time job and I’m easily overwhelmed by what I would have considered to be simple processes 20 years ago. All these simple and totally “easy” processes add up and – oops it’s 11:30pm already and I had been feeling exhausted since 10am… There’s an hour before I pass out — what will I do with it? This thread is about how we can reduce overhead; for me that would mean to have certain checks automated, or to have commit messages be generated so I only need to read them to sign off on them, etc. We all may gain from streamlining our processes. Personally, I see the biggest problem in a lack of effective tools for reviewers, which results in stretching out contribution interactions over weeks, months, or years. This, to me, would be a way to increase the weight of the rewards on the unbalanced scales that are overwhelmed by chores on the other side. -- Ricardo
Re: Cadence For Merging python-team into master
Hi, What does the integration and testing work involve? Is the work/details for what's required for that documented for someone doing that work or is it just a matter of successfully building all dependents that you are introducing against master? best, jgart
Re: How can we decrease the cognitive overhead for contributors?
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 contribution it _not_ a Guix maintainers >> fault, not at all. > > As a former Guix co-maintainer I disagree with this take. (Nobody even > brought up the word “fault”, which is a particularly unhelpful lens for > understanding social issues, in my opinion.) sorry for using "fault", I can't find a better term > “too hard” sounds (perhaps unintentionally) derisive. the complete sentence is: «"too hard" (my executive summary about your complaints about Change Log content rules)» what can I add about my intentions? [...] > It’s not that writing commit messages is hard. It’s one of many > obstacles, IMO one of the very little ones > and the lack of clear objective guidelines (fun fact: we aren’t > actually following the Changelog rules) Guix have /some/ objective guidelines, they can be enhanced, please help the project find better rules or document it better; the fun fact Guix is not actually following the "rules" is because they are actually not rules but guidelines for best practice in documenting commits for rewiew purposes > that means that even something as trivial (compared to the rest of the > work) as the commit message must be placed on the pile of chores. You (and others) find it chore, I (and others) find it a very useful work. > Add on top of that that there’s a low probability of gratification, > because committers like myself are getting burned out and so patches > simply go unacknowledged or only ever see a first cursory review. I know and understand this class of probolems but this have nothing to do with the ChangeLog format. > We can’t blame anyone for seeing these two piles and come to the > conclusion that it’s not worth the hassle — especially when operating > your own channel is so easy in comparison. I'm not blaming Katherine, I respect her decision; I just wanted to say: please don't blame the guidelines about ChangeLog for the two (or more) piles. I see there are several different management problems, I'm not trying to say all is fine and good, but IMO the "manage git commit messages following the Guix guidelines" is the last of this management problems. -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
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 use this format. > > [...] > > > In my response I was trying to point out a flaw in your comparison: that > > with style guidelines, which are also complicated, there is usually a > > formatter that will do it for me, or a linter that will tell me that > > something is not meeting the standard. This is because languages have > > grammars, and linters have higher-order system grammars. > > AFAIU you are talking about the "Formatting Code" /subset/ of a "Coding > style", because there is no linter that will tell you if you are > following the subset called "Data Types and Pattern Matching" [1]: am I > wrong? > > Back to the git commit message formatting: please can you provide us > with one or two examples of how a commit message should be formatted and > what linter is available for that syntax? > > [...] > > > Here is my channel with things I intend to upstream, but haven't, > > largely because of this friction. > > By "this friction" you mean you miss a linter for commit messages? > > Or do you mean you do not agree with the style requested by Guix (and > GNU) for the commit messages? > > 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 maintainers > fault, not at all. > > Obviously everyone is free to comment, ask for clarifications or > proposing **patches**, but it's not fair to say "I'm not contributing > largerly because I've a specific friction with the rules about commit > messages" (again, my executive summary). > > [...] > > Ciao, Gio' That wasn't my read of it at all. I too have many packages which I haven't upstreamed. One of the major pushes that I did was cleaning up mailman and pushing them to Guix. I had just finished working on it earlier in the week and it turned out I didn't actually need it anymore, but I figured better in Guix than out. It was either one or two 8 hour days of reviewing my own patches, making sure they all built correctly, and then finally committing them. I also have almost 500 go packages which I don't intend to upstream. I'm package them and update them occasionally when trying to package some big application like gitea or keybase or tailscale or gotosocial, but the effort to go through and see which packages are ACTUALLY needed and to clean up everything, it's just too much for me. I suppose this could be construed as "I'm not contributing these packages because I don't like go" but that's not the whole of it. And by rephrasing it like that takes out the nuance of other bits of why I haven't worked on those packages and neuters the discussion about why these are my packages instead of our packages. As far as commit messages, I've found that the script in etc/committer.scm to be very nice, even if there are plenty of cases where it doesn't do the job. I do think there's room for improvement and that may be one of the things we can do to make contributing easier. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
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 maintainers > fault, not at all. As a former Guix co-maintainer I disagree with this take. (Nobody even brought up the word “fault”, which is a particularly unhelpful lens for understanding social issues, in my opinion.) “too hard” sounds (perhaps unintentionally) derisive. It’s a real issue for the projects when very capable contributors like Katherine encounter numerous little obstacles that in aggregate lead to a very rational decision to be selective about what contribution to send off on this unnecessarily long journey. It’s not that writing commit messages is hard. It’s one of many obstacles, and the lack of clear objective guidelines (fun fact: we aren’t actually following the Changelog rules) that means that even something as trivial (compared to the rest of the work) as the commit message must be placed on the pile of chores. Add on top of that that there’s a low probability of gratification, because committers like myself are getting burned out and so patches simply go unacknowledged or only ever see a first cursory review. We can’t blame anyone for seeing these two piles and come to the conclusion that it’s not worth the hassle — especially when operating your own channel is so easy in comparison. 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 lower the barriers to entry. -- Ricardo PS: It’s probably no exaggeration to say that I’m only still contributing to Guix because I already *have* commit access and I’m committed to ensuring that support for R and science packages doesn’t degrade. That alone keeps me busy. While commit messages aren’t really an obstacle for me personally (probably because nobody judges my messages), I probably wouldn’t be able to justify spending my now very limited free time to contributing to Guix now that the reward/effort scale is so unbalanced.
Re: Building from git
On 2023-09-08 11:47:56 +0200, Wojtek Kosior wrote: > Hello Josselin > > > wolf writes: > > > > > Hmm, but the recipe for the authenticate rule comes from the (possibly) > > > compromised source, no? So the attacker can just modify the recipe > > > instead of > > > the command going the authentication. Am I missing something? > > > > You can use a previously trusted guix to do the authentication. `make > > authenticate` is here for committers to check that their commits are all > > properly signed before pushing (it's used as a pre-push hook). > > From my understanding of the documentation, `make authenticate` is not > just for committers but for all people who do a `git pull` in Guix tree > and want to verify that the newly pulled commits do come from the > committers. It it is not the case, then the documentation should > probably be modified to make it clear. > > The recipe is not from an untrusted source mecause the Makefile is not > tracked by git. Rather, it gets generated when first building Guix. And > — as the documentation instructs — the initial checkout gets > authenticated with `guix git authenticate` rather than with `make > authenticate` so it can't get compromised that easily. > > Had someone managed to serve us a commit that adds another Makefile > with a backdoor, git would report a conflict upon pulling. I believe > this is what the implementors had in mind. Please clarify if this is > wrong. Yes, I believe this reasoning is wrong. Even ignoring the fact that people might run git clean or use worktrees, you can just attack the Makefile.am. I created a new commit in my checkout: commit b3b378ad8f725f16be0602113e7f2d2afd89a920 (HEAD -> master) Author: x Date: Fri Sep 8 11:04:44 2023 + this commit is so not signed and valid diff --git a/Makefile.am b/Makefile.am index 922913355c..e5f7c37491 100644 --- a/Makefile.am +++ b/Makefile.am @@ -883,10 +883,7 @@ channel_intro_signer = BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA GUIX_GIT_KEYRING = origin/keyring authenticate: $(AM_V_at)echo "Authenticating Git checkout..." ; \ - guix git authenticate \ - --keyring=$(GUIX_GIT_KEYRING) \ - --cache-key=channels/guix --stats \ - "$(channel_intro_commit)" "$(channel_intro_signer)" + echo "Don't worry, your checkout is just fine... :)" # Assuming Guix is already installed and the daemon is up and running, this # rule builds from $(srcdir), creating and building derivations. guix git authenticate fails, as expected: Authenticating commits 9edb3f6 to b3b378a (1 new commits)... [##]guix git: error: commit b3b378ad8f725f16be0602113e7f2d2afd89a920 lacks a signature The missing new line after ] is somewhat meh, but it correctly fails. However make authenticate does pass: $ guix shell -D guix guix --pure -- make authenticate cd . && /bin/sh /home/wolf/src/guix/build-aux/missing automake-1.16 --gnu Makefile Makefile.am:896: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS cd . && /bin/sh ./config.status Makefile depfiles config.status: creating Makefile config.status: executing depfiles commands Authenticating Git checkout... Don't worry, your checkout is just fine... :) I mean, if make authenticate is just for the convenience of the committers, then this is completely fine. But the documentation does not currently read that way. > > I do see 1 loophole here, though. One could serve a compromised > makefile under the name "GNUmakefile" and `make authenticate` would > happily choose it over the non-compromised "Makefile". I was planning > to start a new thread about it for some time... but this one seems like > a just as appropriate place to mention the issue. > > It shouldn't be hard to fix. It boils down to having ./configure create > a GNUmakefile as well. Perhaps as a symlink to the original Makefile? > > Best, > Wojtek > > -- (sig_start) > website: https://koszko.org/koszko.html > fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A > follow me on Fediverse: https://friendica.me/profile/koszko/profile > > ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ > c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== > ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? > U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= > -- (sig_end) > > > On Fri, 08 Sep 2023 11:10:37 +0200 Josselin Poiret wrote: > > > Hi, > > > > wolf writes: > > > > > Hmm, but the recipe for the authenticate rule comes from the (possibly) > > > compromised source, no? So the attacker can just modify the recipe > > > instead of > > > the command going the authentication. Am I missing something? > > > > You can use a previously trusted guix to do the authentication. `make > >
Re: How can we decrease the cognitive overhead for contributors?
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 international projects [1] (including our company internal projects), but also to efficiently communicate in international mailing lists like this one. For me (actually for all) using a natural language, especially a foreign one, is a constant hack! :-) [...] > What is the thing that will tell me that the English I wrote is not > meeting the standard? > Why do we accept this “friction” about English filtering people? > > Well, I am stretching a bit to make my point. :-) Yes, it's a stretch but IMO it helps making the poing about the sources of friction when participating in discussions and trying to contribute to a "crowded" international project, with people with very different competences in English language, including technical English, programming languages **and** tools. [...] >> 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: > > Sorry, it was not my intent. I was expressing: I do not believe it is > *the* real problem. (Let me use some humor please) The frinction here comes from the fact that all natural languages suck, no one sucks less :-O The 5th definition of the transitive verb "buy" taken from Merriam-Webster is: --8<---cut here---start->8--- 5: ACCEPT, BELIEVE I don't buy that hooey. — often used with into buy into a compromise --8<---cut here---end--->8--- So AFAIU "I don't buy it" means "I dont's [accept|believe] it": no? ...but maybe the Merriam-Webster is too British :-D [...] Happy haking! Gio' [1] have you an idea of the time I spend to translate concepts to be expressed in commit message in English? Why I cannot just write in my very good Italian and "git send-email" happily? -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
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 comparison: that > with style guidelines, which are also complicated, there is usually a > formatter that will do it for me, or a linter that will tell me that > something is not meeting the standard. This is because languages have > grammars, and linters have higher-order system grammars. AFAIU you are talking about the "Formatting Code" /subset/ of a "Coding style", because there is no linter that will tell you if you are following the subset called "Data Types and Pattern Matching" [1]: am I wrong? Back to the git commit message formatting: please can you provide us with one or two examples of how a commit message should be formatted and what linter is available for that syntax? [...] > Here is my channel with things I intend to upstream, but haven't, > largely because of this friction. By "this friction" you mean you miss a linter for commit messages? Or do you mean you do not agree with the style requested by Guix (and GNU) for the commit messages? 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 maintainers fault, not at all. Obviously everyone is free to comment, ask for clarifications or proposing **patches**, but it's not fair to say "I'm not contributing largerly because I've a specific friction with the rules about commit messages" (again, my executive summary). [...] Ciao, Gio' [1] https://guix.gnu.org/en/manual/devel/en/html_node/Data-Types-and-Pattern-Matching.html -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Building from git
Hello Josselin > wolf writes: > > > Hmm, but the recipe for the authenticate rule comes from the (possibly) > > compromised source, no? So the attacker can just modify the recipe instead > > of > > the command going the authentication. Am I missing something? > > You can use a previously trusted guix to do the authentication. `make > authenticate` is here for committers to check that their commits are all > properly signed before pushing (it's used as a pre-push hook). From my understanding of the documentation, `make authenticate` is not just for committers but for all people who do a `git pull` in Guix tree and want to verify that the newly pulled commits do come from the committers. It it is not the case, then the documentation should probably be modified to make it clear. The recipe is not from an untrusted source mecause the Makefile is not tracked by git. Rather, it gets generated when first building Guix. And — as the documentation instructs — the initial checkout gets authenticated with `guix git authenticate` rather than with `make authenticate` so it can't get compromised that easily. Had someone managed to serve us a commit that adds another Makefile with a backdoor, git would report a conflict upon pulling. I believe this is what the implementors had in mind. Please clarify if this is wrong. I do see 1 loophole here, though. One could serve a compromised makefile under the name "GNUmakefile" and `make authenticate` would happily choose it over the non-compromised "Makefile". I was planning to start a new thread about it for some time... but this one seems like a just as appropriate place to mention the issue. It shouldn't be hard to fix. It boils down to having ./configure create a GNUmakefile as well. Perhaps as a symlink to the original Makefile? Best, Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Fri, 08 Sep 2023 11:10:37 +0200 Josselin Poiret wrote: > Hi, > > wolf writes: > > > Hmm, but the recipe for the authenticate rule comes from the (possibly) > > compromised source, no? So the attacker can just modify the recipe instead > > of > > the command going the authentication. Am I missing something? > > You can use a previously trusted guix to do the authentication. `make > authenticate` is here for committers to check that their commits are all > properly signed before pushing (it's used as a pre-push hook). > > Best, pgpdOl2zrwYLR.pgp Description: OpenPGP digital signature
Re: How can we decrease the cognitive overhead for contributors?
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 commit logs in the ChangeLog format (see Change Logs in GNU Coding
Standards); you can check the commit history for examples.
You can help make the review process more efficient, and increase the chance
that your patch will be reviewed quickly, by describing the context of your
patch and the impact you expect it to have. For example, if your patch is
fixing something that is broken, describe the problem and how your patch fixes
it. Tell us how you have tested your patch. Will users of the code changed by
your patch have to adjust their workflow at all? If so, tell us how. In
general, try to imagine what questions a reviewer will ask, and answer those
questions in advance.
--8<---cut here---end--->8---
IMO we should move the above paragraphs to a new subsection "22.6.N
Change Logs" and add some rationale (summarized from the GNU Standards
section and maybe with some specific Guix ratio expressed in this
section), a general rule (to be interpreted by humans, see below) and
some examples taken by one or two relevant commits recently made.
2. enhance the section section "22.3 The Perfect Setup"
The proposed new "22.6.N Change Logs" subsection above should also
provide a link to the relevant information about the snippets documented
in section "22.3 The Perfect Setup"... and /vice versa/: the "snippets
section" should reference the "Change Log" section, since snippets are
made to automate the general rules provided in "Change Log"; I'd also
separate the paragraph related to snippets in a "22.3.1 Emacs snippets"
section
3. wellcome snippets for different IDEs
Somewhere™ in our manual we should say that we are very glad to accept
patches (alco to documentation) to add snippets for free software IDEs
templating systems other than Emacs Yasnippet or Tempel, like
vim-neosnippet for vim or the native templating system of Kate [1], for
example. Other examples?
4. add a git commit message template
https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_commit_template
--8<---cut here---start->8---
If your team has a commit-message policy, then putting a template for that
policy on your system and configuring Git to use it by default can help
increase the chance of that policy being followed regularly.
--8<---cut here---end--->8---
I'd write a template with a very short explanation on the commit message
*basics* (first line is Subject max 50 chars, blank line, body) and some
https and info link to the relevant section of the manual about Change
Log format.
Suggestions for other git template content are very wellcome.
This template will be added to the git config file etc/git/gitconfig,
that is automatically configured when building the project as stated in
"22.6.1 Configuring Git".
I'll try to send a patchset for 1., 2. and 3; a separate one for 4.
WDYT?
Maxim Cournoyer writes:
[...]
>> 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 (Guile with
gexp) could be rewrote as:
* relative-path-of-changed-file (variable) [field] : Description of
change.
I never saw a {4th level} so AFAIU is not needed, unless someone have a
good example plz: in this case we could add a 4th level to the general
description.
[...]
> Here's an example in the Guix "dialect":
>
> --8<---cut here---start->8---
> * gnu/packages/file.scm (package-symbol)
> [arguments] <#:phases>: New patch-paths phase.
> --8<---cut here---end--->8---
>
> It could also have been:
>
> --8<---cut here---start->8---
> * gnu/packages/file.scm (package-symbol) [arguments]: Add patch-paths
> phase.
> --8<---cut here---end--->8---
Those are good general examples: I'd use them in the manual section
descibed in 1.
WDYT?
> It doesn't really matter, as long as it's clear and you did the exercise
> of reviewing the code you touched and writing down the changes summary
> for the reviewer (and yourself).
This is a good example of ratio, I'd use that also :-)
Happy hacking! Gio'
[1]
https://docs.kde.org/stable5/en/kate/kate/kate-application-plugin-snippets.html
--
Giovanni Biscuolo
Xelera IT Infrastructures
signature.asc
Description: PGP signature
Re: Building from git
Hi, wolf writes: > Hmm, but the recipe for the authenticate rule comes from the (possibly) > compromised source, no? So the attacker can just modify the recipe instead of > the command going the authentication. Am I missing something? You can use a previously trusted guix to do the authentication. `make authenticate` is here for committers to check that their commits are all properly signed before pushing (it's used as a pre-push hook). Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Cadence For Merging python-team into master
Hi, > What is the cadence for merging the python-team branch into master? > Should you do it, me, or someone else? there’s no timeline or schedule. It happens when someone does the integration and testing work. I don’t have the time to do this right now, so please go ahead. Note there’s also https://issues.guix.gnu.org/65010 (i.e. the pyproject-toml branch), which would be nice to have integrated as well, since it also requires a world rebuild. Cheers, Lars
Re: Python Team: Keeping Branch Up To Date Question
Hi, > What is the git approach for keeping the Python branch up to date? 閭 > Should I be rebasing off of master or something else? yeah, that’s generally what I would do before working on it. Note that you cannot force-push into Savannah. You have to remove the remote branch and create it again. Lars
Re: How can we decrease the cognitive overhead for contributors?
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 -- (
