workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Laura Abbott <labbott@redhat.com>
Cc: Don Zickus <dzickus@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Daniel Axtens <dja@axtens.net>,
	David Miller <davem@davemloft.net>,
	sir@cmpwn.com, nhorman@tuxdriver.com, workflows@vger.kernel.org
Subject: Re: thoughts on a Merge Request based development workflow
Date: Wed, 9 Oct 2019 17:54:16 -0400	[thread overview]
Message-ID: <20191009215416.o2cw6cns3xx3ampl@chatter.i7.local> (raw)
In-Reply-To: <bbf9d038-2238-b97f-7cae-97804ee1624c@redhat.com>

On Wed, Oct 09, 2019 at 05:35:39PM -0400, Laura Abbott wrote:
>>This doesn't mean that forges are entirely out -- but they must remain 
>>mere tools that participate in a globally decentralized, 
>>developer-attestable, self-archiving messaging service. Maybe let's 
>>call that "kernel developer bus" or "kdbus" -- pretty sure that name 
>>hasn't been used before.
>>
>
>The big issue I see with anything decentralized is that as things
>grow people don't actually want to host their own infrastructure.
>Think about the decline in the number of people who host their own
>e-mail server. Anything decentralized would still presumably require
>a server somewhere, so you're going to either raising the bar to entry
>by requiring people to set up their own server or end up with people
>still relying on a service somewhere. This feels like it ends up with
>the situation we have today where most things are locally optimized
>but on average the situation is still lousy.
>
>You've articulated you've articulated the reasons against centralization
>very well from an admin point of view (which I won't dispute) but at
>least from a user point of view a centralized forge infrastructure is
>great because I don't have to worry about it. My university/company
>doesn't have to set anything up for me to contribute. I get we are
>probably going to end up optimizing more for the maintainer here but
>it's worth thinking about how we could get forge-like benefits where
>most users don't have to run infrastructure.

We're actually not in opposition to each-other -- I expect kernel.org
(via Linux Foundation) would provide convenient bridge tools to cover 
the precise concern you mention. Think kind of like 
patchwork.kernel.org, but instead of exclusively using some local 
database that only admins at kernel.org have access to, it would provide 
a set of feeds allowing anyone else to set up a fully functioning 
replica -- or participate in the process using their own compatible 
tools.

So, in other words, the forge is still there and is still providing a 
valuable service, but it is not the single point of truth that can 
vanish and take invaluable data with it. That's my vision, and I think 
we have all we need to achieve it short of resolve, buy-in, and proper 
tooling.

-K

  reply	other threads:[~2019-10-09 21:54 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 18:25 thoughts on a Merge Request based development workflow Neil Horman
2019-09-24 18:37 ` Drew DeVault
2019-09-24 18:53   ` Neil Horman
2019-09-24 20:24     ` Laurent Pinchart
2019-09-24 22:25       ` Neil Horman
2019-09-25 20:50         ` Laurent Pinchart
2019-09-25 21:54           ` Neil Horman
2019-09-26  0:40           ` Neil Horman
2019-09-28 22:58             ` Steven Rostedt
2019-09-28 23:16               ` Dave Airlie
2019-09-28 23:52                 ` Steven Rostedt
2019-10-01  3:22                 ` Daniel Axtens
2019-10-01 21:14                   ` Bjorn Helgaas
2019-09-29 11:57               ` Neil Horman
2019-09-29 12:55                 ` Dmitry Vyukov
2019-09-30  1:00                   ` Neil Horman
2019-09-30  6:05                     ` Dmitry Vyukov
2019-09-30 12:55                       ` Neil Horman
2019-09-30 13:20                         ` Nicolas Belouin
2019-09-30 13:40                         ` Dmitry Vyukov
2019-09-30 21:02                     ` Konstantin Ryabitsev
2019-09-30 14:51                   ` Theodore Y. Ts'o
2019-09-30 15:15                     ` Steven Rostedt
2019-09-30 16:09                       ` Geert Uytterhoeven
2019-09-30 20:56                       ` Konstantin Ryabitsev
2019-10-08  1:00                     ` Stephen Rothwell
2019-09-26 10:23           ` Geert Uytterhoeven
2019-09-26 13:43             ` Neil Horman
2019-10-07 15:33   ` David Miller
2019-10-07 15:35     ` Drew DeVault
2019-10-07 16:20       ` Neil Horman
2019-10-07 16:24         ` Drew DeVault
2019-10-07 18:43           ` David Miller
2019-10-07 19:24             ` Eric Wong
2019-10-07 15:47     ` Steven Rostedt
2019-10-07 18:40       ` David Miller
2019-10-07 18:45       ` David Miller
2019-10-07 19:21         ` Steven Rostedt
2019-10-07 21:49     ` Theodore Y. Ts'o
2019-10-07 23:00     ` Daniel Axtens
2019-10-08  0:39       ` Eric Wong
2019-10-08  1:26         ` Daniel Axtens
2019-10-08  2:11           ` Eric Wong
2019-10-08  3:24             ` Daniel Axtens
2019-10-08  6:03               ` Eric Wong
2019-10-08 10:06                 ` Daniel Axtens
2019-10-08 13:19                   ` Steven Rostedt
2019-10-08 18:46                 ` Rob Herring
2019-10-08 21:36                   ` Eric Wong
2019-10-08  1:17       ` Steven Rostedt
2019-10-08 16:43         ` Don Zickus
2019-10-08 17:17           ` Steven Rostedt
2019-10-08 17:39             ` Don Zickus
2019-10-08 19:05               ` Konstantin Ryabitsev
2019-10-08 20:32                 ` Don Zickus
2019-10-08 21:35                   ` Konstantin Ryabitsev
2019-10-09 21:50                     ` Laura Abbott
2019-10-10 12:48                       ` Neil Horman
2019-10-09 21:35                 ` Laura Abbott
2019-10-09 21:54                   ` Konstantin Ryabitsev [this message]
2019-10-09 22:09                     ` Laura Abbott
2019-10-09 22:19                       ` Dave Airlie
2019-10-09 22:21                     ` Eric Wong
2019-10-09 23:56                       ` Konstantin Ryabitsev
2019-10-10  0:07                         ` Eric Wong
2019-10-10  7:35                         ` Nicolas Belouin
2019-10-10 12:53                           ` Steven Rostedt
2019-10-10 14:21                           ` Dmitry Vyukov
2019-10-11  7:12                             ` Nicolas Belouin
2019-10-11 13:56                               ` Dmitry Vyukov
2019-10-14  7:31                                 ` Nicolas Belouin
2019-10-10 17:52                     ` Dmitry Vyukov
2019-10-10 20:57                       ` Theodore Y. Ts'o
2019-10-11 11:01                         ` Dmitry Vyukov
2019-10-11 12:54                           ` Theodore Y. Ts'o
2019-10-14 19:08                         ` Han-Wen Nienhuys
2019-10-15  1:54                           ` Theodore Y. Ts'o
2019-10-15 12:00                             ` Daniel Vetter
2019-10-15 13:14                               ` Han-Wen Nienhuys
2019-10-15 13:45                                 ` Daniel Vetter
2019-10-16 18:56                                   ` Han-Wen Nienhuys
2019-10-16 19:08                                     ` Mark Brown
2019-10-17 10:22                                       ` Han-Wen Nienhuys
2019-10-17 11:24                                         ` Mark Brown
2019-10-17 11:49                                     ` Daniel Vetter
2019-10-17 12:09                                       ` Han-Wen Nienhuys
2019-10-17 12:53                                         ` Daniel Vetter
2019-10-15 16:07                           ` Greg KH
2019-10-15 16:35                             ` Steven Rostedt
2019-10-15 18:58                             ` Han-Wen Nienhuys
2019-10-15 19:33                               ` Greg KH
2019-10-15 20:03                                 ` Mark Brown
2019-10-15 19:50                               ` Mark Brown
2019-10-15 18:37                           ` Konstantin Ryabitsev
2019-10-15 19:15                             ` Han-Wen Nienhuys
2019-10-15 19:35                               ` Greg KH
2019-10-15 19:41                               ` Konstantin Ryabitsev
2019-10-16 18:33                                 ` Han-Wen Nienhuys
2019-10-09  2:02           ` Daniel Axtens
2019-09-24 23:15 ` David Rientjes
2019-09-25  6:35   ` Toke Høiland-Jørgensen
2019-09-25 10:49   ` Neil Horman

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=20191009215416.o2cw6cns3xx3ampl@chatter.i7.local \
    --to=konstantin@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=dja@axtens.net \
    --cc=dzickus@redhat.com \
    --cc=labbott@redhat.com \
    --cc=nhorman@tuxdriver.com \
    --cc=rostedt@goodmis.org \
    --cc=sir@cmpwn.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;
as well as URLs for NNTP newsgroup(s).