Re: On commit access, patch review, and remaining healthy
Hello,
As a new-new Guix user, I did find the review process or the time
it takes really long.
Maybe I've tackle too complex updates[0], I don't know but I don't
have a clear path how to push it.
As a dev, I am not super used to the email-patches workflow, I am
more used to the pull-request
git{hub|lab} process and do work on large open source project and
reviewing code is a tedious but necessary task.
Also, I don't want to say that one workflow is superior to the
other but one thing that shines with theses forge
is the automation and the simplicity to add tooling on pull
request to reduce the burden to the reviewer:
- linting
- checks
- commits log formatting check
- CI jobs
- codeowner assignment
- build packages (partial or complete rebuild the world if needed)
- license check
- notification for stable pull request.
All theses are useful quality of life improvement for reviewers
and reduce some of the friction and remove some of the
non glamourous-task. Maybe it could be added to Mumi? Maybe a bot
like Ofborg in NixOS could take care of some of the operation.
I haven't watched Arun presentation, I will search the list if the
recording is up somewhere.
Guix is cool project, I am super happy to use it and would like to
help more.
ph
[0]: https://issues.guix.gnu.org/55210
Ludovic Courtès writes:
Hello Guix!
Following on the theme of patch review, I did some stats with
the
attached tools on commits since 1.3.0:
• 20,489 commits were made since then;
• 4,476 were commits pushed on behalf of a non-committer;
• of these, half were pushed by 2 committers, out of 40ish.
Some conclusions we can draw:
• We have a strong core development team, which I think is
great
compared to many free software projects.
Perhaps the flip side of this is that we make too little
space to
newcomers. (I feel we’re almost the opposite of a typical
Git{Hub,Lab}-hosted project where drive-by contributions are
common
and long-term commitment is rare.)
• Review work is severely lacking. The manual reads (info
"(guix)
Commit Access"):
[…] the project keeps moving forward because committers
not only push
their own awesome changes, but also offer some of their
time
_reviewing_ and pushing other people’s changes. As a
committer,
you’re welcome to use your expertise and commit rights to
help
other contributors, too!
Yet, most committers don’t allocate time to review and push
other
people’s changes.
Why aren’t we, committers, not doing more review/apply work?
Is it
too intimidating? Would having a documented review
checklist help?
If you’re not using Emacs, what actionable steps should we
take with
mumi and other tools to help you (Arun made several
proposals in
their Guix Days talk)? If you are using Emacs, does
debbugs.el have
shortcomings that make it a problem to review patches?
• We need to be able to renew committers. There’s a process
in place
to remove, at least temporarily, committers that have been
inactive
for a year or more, and I think it’s good (info "(guix)
Commit
Access").
Maybe we should also encourage committers who have “moved
on” to let
the project know so we have a clearer picture of who’s
in—meaning
available not just to commit their own occasional patches,
but also
to help other contributors.
In addition to that, we need to encourage contributors who
are not
committers yet, which obviously means reviewing and applying
their
contributions in a timely fashion. We need to grow prolific
contributors into leadership positions to they can become
committers
and take part into this whole process.
In short, we need to break out of a potentially vicious circle
where
active members don’t make the work that would allow newcomers to
get
more involved, at the risk of burning out themselves.
Let’s make sure this project keeps striving for decades to come!
:-)
Thoughts?
Ludo’.
(use-modules (git)
(git repository)
(git reference)
(git oid)
(git tag)
(git commit)
(git structs)
;signature-email, etc.
(guix git)
(srfi srfi-1)
(srfi srfi-26)
(ice-9 match)
(ice-9 vlist))
(define commit-author*
(compose signature-name commit-author))
(define commit-committer*
(compose signature-name commit-committer))
(define-syntax-rule (false-if-git-error exp)
(catch 'git-error
(lambda () exp)
(const #f)))
(define* (fold-commits proc seed repo
#:key
(start (reference-target
(repository-head repo)))
end)
"Call PROC on each commit of REPO, starting at START
Docker 19.x eol
Hello, Is there anyone working on updating the docker packages to 20.x I believe Guix ships with 19.x this is EOL if I remember it’s EOL. If someone working on it I will be happy to help. Thanks Sent from my internet monolith
Re: Updating from Go 1.17 to 1.18
Hello Katherine and Ludovic, I've finally had the time to push the patches[0], my house was hit hard by sickness. Concerning having Go 1.18 as the default version, I think it's on Ludovic side to create a branch to see where things breaks.. Not sure where the outputs will be but I am sure we will have a few dependencies to fix It will be good to work together to fix them. Thanks [0] https://issues.guix.gnu.org/55210 On Thu, Apr 21, 2022 at 10:58 AM Katherine Cox-Buday < cox.katherin...@gmail.com> wrote: > Pier-Hugues Pellerin writes: > > > We should probably also try to mimic how their bootstrap and have the > > following: > > > >- Bootstrap 1.17 with 1.4 > >- Bootstrap 1.18 with 1.4 > >- Have 1.19 bootstrap with 1.17. > > > > So maybe we should do something like this. > > > > - Add go-1.18 build from 1.4. > > - Add go-next that point to go-1.18 > > - Refactor 1.17 package definition that is shared between go-1.18. and > > go-1.17. > > - Move go to go-1.18 in another branch > > - Remove 1.16? > > Thanks for looking into how the Go team will be bootstrapping, and I > agree with your plan. Is there anything I can do to help? > > -- > Katherine > -- ph
Re: Updating from Go 1.17 to 1.18
Hello, I've looked a bit more in detail on the Go package definition, Maybe we should rethink how we are building the Go package in guix? If I understand correctly, the current bootstrap chain is the following. 1.17 -> 1.16-> 1.4 which is the last gcc version of go. Looking at the current proposal in Go https://mail.google.com/mail/u/0/#inbox/KtbxLthKLdQNrjXvKllfQHQBQcKqVFdmPg I don't think we will be able to remove 1.17 soon and also 1.4. Because they want to move to use 1.17 as the minimum version in the next minor. We should probably also try to mimic how their bootstrap and have the following: - Bootstrap 1.17 with 1.4 - Bootstrap 1.18 with 1.4 - Have 1.19 bootstrap with 1.17. So maybe we should do something like this. - Add go-1.18 build from 1.4. - Add go-next that point to go-1.18 - Refactor 1.17 package definition that is shared between go-1.18. and go-1.17. - Move go to go-1.18 in another branch - Remove 1.16? WDYT? I am not super familiar with the scheme but this seems like a good exercise. Thanks On Wed, Apr 20, 2022 at 7:43 PM Pier-Hugues Pellerin wrote: > That sound great and great timing I was working on that as you send the > mail > > I think also go-next is a good idea, I will split them in the following > commits: > > 1. Add go-1.17 inherits from 1.18 (actually reversing the patch in the > previous email) > 2. Add go-next pointing to 1.18. > 3. Make go point to 1.18. > > This will allow merging things right away to add support for go 1.18 and > also allow Ludovic to create the branch and rebuild. > > Thanks > > On Wed, Apr 20, 2022 at 7:36 PM Katherine Cox-Buday < > cox.katherin...@gmail.com> wrote: > >> >>> Pier-Hugues Pellerin writes: >> >> Ludovic Courtès writes: >> >> >>> I am trying to update Go to 1.18, I do have a *working* patch that >> defines >> >>> a package that inherits from 1.17 and that adjusts the inputs. >> >> >> >> Nice! >> >> Yes, thank you! I just found out I need this and came to see if anyone had >> started on it. >> >> >> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have >> both >> >> versions, and eventually we’ll remove the older one. >> >> I suggest inverting this: copy/paste go-1.17 to go-1.18, and then make >> go-1.17 >> inherit from go-1.18. This means that when it's time to sunset a version, >> it's >> a simple delete and not something that cascades through all recent >> versions. >> >> > I think it makes sense, looking at the number of impacted packages and >> from >> > my experience working in go, even if the contract is the same, >> sometimes it >> > does break on minor. >> >> I was wondering if we don't want to start publishing a go-next package >> like we do with emacs-next? That would allow us to publish the latest >> version of Go without needing to immediately address building all the >> packages that depend on it. >> >> Kindest regards, >> -- >> Katherine >> > > > -- > ph, > http://heykimo.com > -- ph, http://heykimo.com
Re: Updating from Go 1.17 to 1.18
That sound great and great timing I was working on that as you send the mail I think also go-next is a good idea, I will split them in the following commits: 1. Add go-1.17 inherits from 1.18 (actually reversing the patch in the previous email) 2. Add go-next pointing to 1.18. 3. Make go point to 1.18. This will allow merging things right away to add support for go 1.18 and also allow Ludovic to create the branch and rebuild. Thanks On Wed, Apr 20, 2022 at 7:36 PM Katherine Cox-Buday < cox.katherin...@gmail.com> wrote: > >>> Pier-Hugues Pellerin writes: > >> Ludovic Courtès writes: > > >>> I am trying to update Go to 1.18, I do have a *working* patch that > defines > >>> a package that inherits from 1.17 and that adjusts the inputs. > >> > >> Nice! > > Yes, thank you! I just found out I need this and came to see if anyone had > started on it. > > >> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have > both > >> versions, and eventually we’ll remove the older one. > > I suggest inverting this: copy/paste go-1.17 to go-1.18, and then make > go-1.17 > inherit from go-1.18. This means that when it's time to sunset a version, > it's > a simple delete and not something that cascades through all recent > versions. > > > I think it makes sense, looking at the number of impacted packages and > from > > my experience working in go, even if the contract is the same, sometimes > it > > does break on minor. > > I was wondering if we don't want to start publishing a go-next package > like we do with emacs-next? That would allow us to publish the latest > version of Go without needing to immediately address building all the > packages that depend on it. > > Kindest regards, > -- > Katherine > -- ph, http://heykimo.com
Re: go libraries do not work in a guix shell
Hello, Is that a new behaviour? I’ve recently updated go to package to 1.17.8. Sent from my portable monolith. Ph > On Apr 16, 2022, at 12:09 PM, jgart wrote: > > Hi Guixers, > > go libraries do not work in a guix shell. > > Some user experience reports: > > 2022-04-13 23:40:32Go works in guix shell, but you have to add > other stuff like glibc and I think binutils > > http://litterbox.whereis.みんな/scooper/events?network=Libera.Chat&context=%23whereiseveryone&before=2022-04-13T23%3A44%3A15#4030 > > This is what I tried without success: > > guix shell go go-github-com-dchest-captcha go-github-com-matryer-is > go-github-com-mattn-go-sqlite3 sqlite --pure -L ~/guixrus > > Once in the shell, the go compiler would complain of not finding the > libraries. > > How should we start investigating this? > > My ideal experience with go libraries would be the same as for python, > haskell, common lisp, guile, etc... > > all best, > > jgart > >
Re: Updating from Go 1.17 to 1.18
Hello, I think it makes sense, looking at the number of impacted packages and from my experience working in go, even if the contract is the same, sometimes it does break on minor. One more thing, should I do it in two patches like this? 1. Add go 1.18 inheriting from 1.17, allowing people to use 1.18 sooner? 2. Move to the default Go to 1.18 with (define-public go go-1.17) and create the testing branch from that? Thanks for the `refresh` tips. On Sun, Apr 10, 2022 at 4:45 PM Ludovic Courtès wrote: > Hi, > > Pier-Hugues Pellerin skribis: > > > I am trying to update Go to 1.18, I do have a *working* patch that > defines > > a package that inherits from 1.17 and that adjusts the inputs. > > Nice! > > > However, I have a few questions: > > > > 1. Is inheriting the way to do that? The package's build system appears > to > > be the same from 1.17. > > 2. How can I rebuild dependents packages to ensure they are still > building > > correctly? > > 3. Anything I should look into or test more for these kinds of packages? > > You can define Go 1.18 inheriting from 1.17; that’ll allow us to have > both versions, and eventually we’ll remove the older one. > > Note that, to actually migrate Go packages to 1.18, you’ll need to > additionally change this line: > > (define-public go go-1.17) > > ‘guix refresh -l go@1.17’ shows the “contour” of the set of packages > that currently depend on Go 1.17. These are all the packages that need > to be rebuilt if you change the line above. Since that’s a lot of them, > we could set up a dedicated branch and have it built by ci.guix. We’d > merge it once problems have been resolved. > > Does that make sense? > > Thanks, > Ludo’. > -- ph, http://heykimo.com
Updating from Go 1.17 to 1.18
Hello, I am trying to update Go to 1.18, I do have a *working* patch that defines a package that inherits from 1.17 and that adjusts the inputs. However, I have a few questions: 1. Is inheriting the way to do that? The package's build system appears to be the same from 1.17. 2. How can I rebuild dependents packages to ensure they are still building correctly? 3. Anything I should look into or test more for these kinds of packages? Thanks -- ph, http://heykimo.com go-1.18 Description: Binary data
