Thanks for helping out with reviews! <3
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).
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.
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:
> 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
On Wed, 03 Feb, 2021 at 14:35:49 +0100, andi@srht.l.notmuch.email wrote:
> 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 :)
> 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:
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) :)
On 03-02-2021 15:47:15, Michael Weiss wrote:
> > 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?
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!)
> Anyway, thanks for working on this (of course this also applies to> everyone else on the mailing list) :)
Yes, definitively a big thanks!
Github at least sends mails for PRs and comments, but that's far from nice,
actually and does not provide a real patch based workflow.
Matthias
On 17:33 03.02.21, Matthias Beyer wrote:
> On 03-02-2021 15:47:15, Michael Weiss wrote:> > > 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'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. 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.
> 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!)
I'll have a look but this sounds like we will end up reinventinb
patchwork. Patchwork already collects "tags" from mail threads:
https://github.com/getpatchwork/patchwork/blob/bdb049c7939b7cdea1eddf029a0bc47cb338da67/docs/usage/overview.rst#tags
I didn't want to enter the mail-thread-reconstruction business with my
tooling yet thus I've just gone for one patch at a time. The amount of
multi-patch changesets that have been submitted here (purposely, aka
those that actually required to be applied in order) is so far zero.
On 03-02-2021 19:22:41, andi@srht.l.notmuch.email wrote:
> 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.
I thought a bit about that: I don't think that is actually necessary.
The point is: With an own domain, you are tied to your own domain - you gain
nothing, except responsibility if things break.
sourcehut (or even: a ML) is a perfect fit because you can always take your mail
archive and go away.
Moving to an own domain is just effort wasted, because short-term or even
mid-term you gain exactly nothing except that you have to invest time into
things that do not result in direct benefit for the cause (which is contributing
to nixpkgs in this case).
As long as your tooling is not bound to sourcehut, but to "mail", I don't see
any value in moving away from sourcehut.
Just my 2ct of course.
Matthias
On Sat, 06 Feb, 2021 at 12:17:53 +0100, Matthias Beyer wrote:
> On 03-02-2021 19:22:41, andi@srht.l.notmuch.email wrote:> > 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.
I agree with both of you. IMO:
- Something like nixpkgs-dev@lists.nixos.org would be nice to have at
some point / when there are enough users (it would make this list
official and we'd have full control over the hosting if we need to;
also: we wouldn't have to host the list and lists.sr.ht might even
support this in the future [0]).
- But it isn't important right now and switching to a different list
shouldn't be too disruptive (maybe Drew would even setup a forwarding
for mails to this list to the new one if we'd ask him nicely and if
not we could e.g. subscribe a "bot" to ease the transition).
> I thought a bit about that: I don't think that is actually necessary.> The point is: With an own domain, you are tied to your own domain - you gain> nothing, except responsibility if things break.
Yeah, IMO only a subdomain of nixos.org (or some other official
Org-owned domain) would make sense. That way we'd only have to add the
DNS records once and it shouldn't make things worse.
[0]: https://todo.sr.ht/~sircmpwn/lists.sr.ht/40
PS: Oh and I agree that nixos.wiki seems like a good place to document
this list and the workflow.
PPS: Also just my 2ct of course.
On 06-02-2021 14:29:28, Michael Weiss wrote:
> - 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
On Wed, Feb 03 2021, andi@srht.l.notmuch.email wrote:
> 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.
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.
Matthias Beyer <mail@beyermatthias.de> writes:
> On 06-02-2021 16:34:10, Xinglu Chen wrote:>> It would be really nice if we could host a public-inbox archive [1],>> I agree.
I also agree and was going to suggest this. Konstantin Ryabitsev[1] has a
neat looking tool called b4[2] for working with public-inbox archives,
which does some of the things that were mentioned in this thread.
[1] Konstantin Ryabitsev <konstantin@linuxfoundation.org>
[2] https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
On 06-02-2021 10:02:55, William Casarin wrote:
> 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