[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210323231106.GA7165@dcvr>
Date: Tue, 23 Mar 2021 23:11:06 +0000
From: Eric Wong <e@...24.org>
To: workflows@...r.kernel.org
Cc: James Bottomley <James.Bottomley@...senpartnership.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thorsten Leemhuis <linux@...mhuis.info>,
ksummit-discuss@...ts.linuxfoundation.org,
Greg KH <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [Ksummit-discuss] RFC: create mailing list "linux-issues"
focussed on issues/bugs and regressions
Konstantin Ryabitsev <konstantin@...uxfoundation.org> wrote:
> On Tue, Mar 23, 2021 at 09:30:33AM -0700, James Bottomley wrote:
> > > I think the bulk of user issues are going to be regressions. Although
> > > you may be in a better position to know for sure, but at least for
> > > me, wearing my "user" hat, the thing that gets me the most is
> > > upgrading to a new kernel and suddenly something that use to work no
> > > longer does. And that is the definition of a regression. My test
> > > boxes still run old distros (one is running fedora 13). These are the
> > > boxes that catch the most issues, and if they do, they are pretty
> > > much guaranteed to be a regression.
> > >
> > > I like the "linux-regressions" mailing list idea.
> >
> > Can't we use the fancy features of public inbox to get the best of both
> > worlds? Have the bug list (or even a collection of lists) but make the
> > linux-regressions one a virtual list keying off an imap flag which a
> > group of people control. That way anything that is flagged as a
> > regression appears in that public inbox. I assume the search can be
> > quite wide so we could flag a regression on any list indexed by lore?
The lei (local email interface) data model will have "labels"(*)
and developers will be able to publish mail with it via static
HTML/Atom/JSON feed via cronjob and whatnot.
> There's a number of ways we can accomplish this, sure.
>
> However, this functionality is not in production yet, and I'm not sure which
> upcoming public-inbox features we'll be implementing as a public
> lore.kernel.org service,
> which ones we'll only offer to kernel.org account holders,
lei could offer read-write JMAP support; either as a CGI tied
to Unix user accounts or some virtual user system. Some fixes
I'm currently making to speed up the test suite will also make
it more suitable for a largish virtual user system.
> and which ones should really be running locally by developers
> themselves.
lei will be MY dream mail/git tool that fills in the gaps
left by other tools; I hope it can make others happy, too :)
> So, I don't want to say either yes or no to this one for the fear of
> over-promising. I guess this is why I'm not in sales. :)
Heh, same here. Once I start using lei to handle all of my mail
and there's a data-loss bug, I could conceivably never know
about it because the bug reports would be lost... :x
[1] "labels" are "mailboxes" in JMAP-speak; and lei's per-user data
model will be tied to JMAP. "keywords" are Maildir/IMAP-system
flags (seen/flagged/answered/...). JMAP doesn't allow arbitrary
keywords, but does allow arbitrary labels.
Powered by blists - more mailing lists