From: Bjorn Helgaas <helgaas@kernel.org>
To: Eric Wong <e@80x24.org>
Cc: Han-Wen Nienhuys <hanwen@google.com>, workflows@vger.kernel.org
Subject: Re: Lyon meeting notes
Date: Tue, 29 Oct 2019 18:13:13 -0500 [thread overview]
Message-ID: <20191029231313.GA124865@google.com> (raw)
In-Reply-To: <20191029222629.GA19318@dcvr>
On Tue, Oct 29, 2019 at 10:26:29PM +0000, Eric Wong wrote:
> > https://docs.google.com/document/d/1khLOBw5-HyaaNX7xregpHQLSfvGDUeHDY921bkI-_os/edit?usp=sharing
>
> Thanks for taking notes. Is there a version accessible to users
> without JavaScript? Thanks.
Here it is:
Present:
* Konstantin Ryabitsev - technical director LF
* Google: Han-Wen Nienhuys, Dmitri Vyukov, David Gow, Brendan Higgins
* Christian Brauner - Canonical
* Shuah Khan - LF
* Greg KH
* Johan Holvold
* Kevin Hilman, KernelCI
* Veronika Kabatova - Red Hat/CKI CI
* Rafael Wysocki - intel
* Sasha Levin
* Frank Rowand
* Daniel Diaz - Linaro LKFT CI
* Daniel Vetter - intel
* Wolfram Sang
* Anasse Astier - freebox (?)
Consensus:
* Current situation is suboptimal/problematic
* CI folks
* Patchwork streamlines workflow; lot of activity now. Dormant for years, but now improving.
* Konstantin: patches: no attestation; no security. Easy to slip in vulns
* Linus checks sigs, but subsystem maintainers don’t.
* Konstantin: proposes minisign signatures.
* How realistic is this? (Steven).
* How big is the key? Ed25519 are short keys.
* Identity tracking? PGP giving up on key signing. TOFU.
* (unhearable)
* KR: signify/minisign background.
* PGP
* KR: Want it to be part of git.
* PGP signatures are attachments. Attachments are easily stripped from message.
* KR: want to archive history
* Complex patch doesn’t get in immediately, because patches need comment rounds, then spoofing gets exposed.
* Greg: base tree information will be great.
* Konstantin wants to put it into Git.
* Base tree
* Discuss base commit
* Hanwen: SHA1 is opaque too
* KR: Linus complains that Changeid is equivalent to messageid, not so much opaqueness.
* Hanwen: suggest to add a public URL to the base tree
* Base goes into email; --base option git-format-patch.
* Must become a requirement
* Put into check-patch
* Similar to signed-off
* Not mandatory, andrew morton not using git. RFC patches also don’t need it.
* Gateways:
* Point to tree, send from system
* Inside corporations, HTTPS.
* Adopt Gitgitgadget from github; creates mail patches from a GH repo.
* Command line tool
* Figuring out who to send this to.
* Automation defeats attestation goal.
* KR: should just build gitgitgadet for kernel.
* How to know whom to send patch to?
* So much cruft in maintainers file.
* Interaction git-format-patch and config is tricky.
* Dmitrii Vyukov:
* Can have a server to do this
* KR: don’t want centralized infrastructure
* Dmitrii: but gitgitgadget is the same?
* (14:35): feeds.
* Human consumable information
* Kernel.org can aggregate all the feeds, and can tell what CIs are still missing.
* CI mail has logs, but the results are transient
* Kernel.org can archive all these data.
* Will be a lot of data, but want to start with feed.
* Needs a common structured format to understand what all CI systems have done.
* Attestation
* Steven: could record the acks/reviewed-by.
* 2nd part of discussion: tooling.
* Lore 200 Gb.
* [lost a lot of conversation here]
* Patchwork:
* Has a web interface
* Can run locally.
* Inbox vs patchwork
* Patchwork with approvals from different maintainers.
* ...
* KR: write local command to work with patchwork.
* KR: daniel uses gitlab, some people want to use gerrit
* KR: wants to have a feed of data.
* Mail from gerrit/gitlab, usually is noisy.
* Tool can consume that feed.
* Libc mailing list, still struggling
* Hanwen: Funding for tooling? Does Linux Foundation build the bridges, or do tool owners (gerrit, gitlab) have to do it?
* Linux Foundation can go to companies to ask for funding
* KR trying to get consensus so we can ask for resources & funding as a group.
* Let people use tools, sourcehut, gitlab, gerrit
* KR: Lore.kernel.org:
* Want to be able to search all over all data, gerrit, kernel etc. (like code search)
* Find all the patches that touch XYZ
* Devs can miss reviews because people don’t know where reviews happen.
* KR: have a bot that will respond on behalf if maintainer has no gerrit account.
* KR: long time initiative: want to move to SSB.
next prev parent reply other threads:[~2019-10-29 23:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 15:41 Han-Wen Nienhuys
2019-10-29 22:26 ` Eric Wong
2019-10-29 23:13 ` Bjorn Helgaas [this message]
2019-11-01 20:07 ` Konstantin Ryabitsev
2019-11-01 20:46 ` Geert Uytterhoeven
2019-11-01 21:30 ` Theodore Y. Ts'o
2019-11-02 1:17 ` Eric Wong
2019-11-01 21:34 ` Dmitry Vyukov
2019-10-29 22:35 ` Daniel Axtens
2019-11-01 17:29 ` Konstantin Ryabitsev
2019-11-01 17:35 ` Dmitry Vyukov
2019-11-02 11:46 ` Steven Rostedt
2019-10-30 9:21 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191029231313.GA124865@google.com \
--to=helgaas@kernel.org \
--cc=e@80x24.org \
--cc=hanwen@google.com \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox