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) :)
And a bit of nix+shell glue around the script:
[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. I would love to run
this ML on a domain that we control so we can move from sr.ht to
Yep, that sounds like the right approach.
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).
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: