Re: thoughts on a Merge Request based development workflow

[Dave Airlie <airlied@gmail.com>]

On Thu, 10 Oct 2019 at 08:09, Laura Abbott <labbott@redhat.com> wrote:
>
> On 10/9/19 5:54 PM, Konstantin Ryabitsev wrote:
> > 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.
> >
>
> I'll admit I'm skeptical about the "participate with their own tools"
> bit, simply because you end up with too many sides arguing about
> standards and either n buggy implementations or effectively a single
> implementation anyway.

I'm with Laura, at the point where you have to write a fully qualified
spec just so few people can keep their own workflows I feel you've
taken things too far.

Dave.