Matthias Beyer: 1
libaom: 2.0.0 -> 2.0.1
1 files changed, 2 insertions(+), 2 deletions(-)
Thanks for helping out with reviews! <3
No problem ;)
But unfortunately I'm already pretty busy with other stuff so I'm not
subscribed and can only handle patches where I'm cc'ed as maintainer :o
But I already knew about this ML and really like the idea :)
I've been a bit slacking in the last few weeks.
Usually, at least last time this was discussed[0], the preferred way of
handling these patches is to open a PR to allow other maintainers to
comment on the patches. I am not happy with that situation as that
essentially multiplies but freedom has never been for free (and not
wanting to use GitHub is a value that I support).
Yeah, I noticed this while looking at some other mails and IMO it makes
sense for the additional CI checks (e.g. AArch64 and meta attributes).
But in this case it was a trivial update that only contained three small
commits so I decided to skip the PR step.
One more small nit: I usually try to keep the reference to the mail that
submitted the patch in the commit message so, at some point in the
future, we enable users to look them up. This is basically inline with
the "Cherrypicked from ...." lines that we add to backports.
I wasn't aware of this but I really like that approach!
Since that job is boring and annoying I wrote a small [python script] that
takes care of that. And I integrated into my (neo)mutt workflow with a
keybind:
Cool :) Maybe it would make sense to publish that information somewhere?
I haven't tested sr.ht wikis yet but that could be appropriate:
This! The more workflow tools are available, the better.
What I deeply miss in the whole email workflow is a tool that aggregates mail
trailers.
For example if I see patches from Alice in my inbox and reply to individual
patches or the whole set with "Reviewed-By: ..." and Bob then applies the
patchset, he might want to automatically include my trailers in the commit
message.
Somewhere is a blog article from Greg KH that he does this by hand (what the
actual hell)!
A tool for this would be awesome!
I started writing one (in Rust), but it is far from working (also because mail
libraries in Rust are just not there yet):
https://git.beyermatthi.as/amt/tree/src/main.rs
(don't use this! You have been warned!)
https://man.sr.ht/wiki/create (and since they're Git repos others could
also improve it, etc.).
Then you could update the description for the mailing list
(https://lists.sr.ht/~andir/nixpkgs-dev) and e.g. links to two wiki
pages for contributors and reviewers (to make it easier to get started
and prevent idiots like me from messing up the workflow... :D).
Anyway, thanks for working on this (of course this also applies to
everyone else on the mailing list) :)
> macro index,pager <F7> \
> "<enter-command>unset wait_key<enter><pipe-message>tee `echo ${XDG_RUNTIME_DIR:-$HOME/.cache}/mail2pr-nixpkgs`<enter><shell-escape>/nix/store/m71wrhr46iv1034j9rw7m96rlcv9j0yz-mail2nixpkgspr `echo ${XDG_RUNTIME_DIR:-$HOME/.cache}/mail2pr-nixpkgs`<enter><enter-command>set wait_key<enter>" \
> "apply patch to nixpkgs and open review shell"
And a bit of nix+shell glue around the script:
> mail2nixpkgspr = let
> path = pkgs.buildEnv {
> name = "mail2nixpkgspr-env";
> paths = [
> pkgs.mail2pr
> pkgs.fzf
> pkgs.gitAndTools.gitFull
> pkgs.gitAndTools.hub
> pkgs.ncurses
> pkgs.coreutils
> ];
> };
> in pkgs.writeShellScript "mail2nixpkgspr" ''
> PATH="${path}/bin:$PATH"
> clear
> exec mail2pr --repo /home/andi/dev/nixos/nixpkgs \
> --base "$(echo -e "master\nstaging\nstaging-next\nrelease-20.09" | fzf --prompt 'base branch')" \
> --github-user andir \
> --github-org nixos \
> --github-repo nixpkgs \
> "$@"
> '';
[0]: https://discourse.nixos.org/t/discourse-patch-submission-is-not-fit-for-purpose/4757/28
[python script]: https://github.com/andir/mail2pr
> I'll see about writing a blog post and maybe some documentation about
> this soon(tm). The nixos.wiki might be a good place to document this as
> this workflow isn't really officially supported.
Yep, that sounds like the right approach.
> I would love to run this ML on a domain that we control so we can move
> from sr.ht to self-hosted etc.. as we need to. Right now we are tied
> to this platform (again) due to the fact that I just wanted to play
> around with this idea.
It would be really nice if we could host a public-inbox archive [1],
this would allow people to subscribe via Atom or NNTP so their mailboxes
won’t get filled with emails. There is also a web interface where you
can search for messages, and you can download threads as an mbox file.
I agree.
For those interested, there is an Emacs package for integration of
public-inbox, git and email [2].
[1]: https://public-inbox.org/public-inbox.git/about/
[2]: https://git.kyleam.com/piem/about/
Just some of my own thoughts.
> - Something like nixpkgs-dev@lists.nixos.org would be nice to have at
> some point [...]
It would require a HUGE political investment to get the nixos/nixpkgs community
to start a mailinglist again.
They killed the wiki because they thought it would be better to document
everything in the repository. This resulted in the worst downgrade in regards to
documentation I have ever seen in a community.
Then they killed the ML, replaced it with discourse, which resulted in the worst
downgrade in user-freedom (regarding preffered UI) I have ever seen in a
community (disourses' mail feature does not count, it's barely usable).
My point is: The nixos community is predestined in bad descisions - at least bad
from our view.
I don't think we will be able to get them to even host a ML within the year.
I would love to see myself disproved, of course!
Matthias
Matthias Beyer <mail@beyermatthias.de> writes:
> https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
This seems to be really cool and exactly what I thought of.
Not sure, though, how much this is bound to kernel lists or whether this is just
the default configuration of the tool?
Matthias