Hi KS organizers (and others),
This is a late topic proposal, hopefully there is still time on the agenda.
We’ve recently been discussing some maintainer model changes as
described below, and would like a slot to discuss the idea and solicit
feedback/comments from the others there.
This started with Arnd and I finally being in one place at the same
time, and talking about how we want to evolve arm-soc maintainership
moving forward. We've been independently thinking of ways to expand
the group and making it more self-service for everybody, but there's a
bunch of tooling needed to make it run smoothly beyond the smaller
group we have now.
In the end, we ended up looking at it from a slightly different angle:
Right now, when contributors show up with new platform support, the
first hill they need to climb is figuring out how they need to carve
up their platform among all the various maintainers, how to make sure
they're all handshaking on keeping things stable, and get code
submitted. It's awkward, not well documented and one of the biggest
overheads we have on our side as well.
When we started talking to other maintainers, we're also realizing
that we are currently duplicating a lot of work. In particular, we
often all get cc:d on patch series, so we all need to read and filter,
and assume that other maintainers spot the right patches, etc.
We have discussed a few different options, and it seems like pooling
more of the contribution flow to a group of co-maintainers is a useful
approach. Initially, we're considering the arm-soc platforms, clock
drivers and pinctrl drivers, which all tend to be affected by new
platform contributions in this way, and often end up cross-cc:d on
everything. Additionally, the flow for successfully merging a new
platform or SoC needs to be documented and advertised. This is true
whether or not we change the way that maintainers coordinate amongst
themselves, or whether or not we change the current workflow used by
platform contributors today.
So, we're planning to change things up a bit. We're starting a new
group that pools current arm-soc, clk and pinctrl drivers and
maintainers into one funnel. We'll set up a new mail alias for the
maintainer group, and one shared patchwork to collect contributions.
We still expect developers to use existing mailing lists, and we still
expect for example ARM platform maintainers to keep their workflow of
collecting patches for their platform like they do today. Down the
road it might make sense to incorporate other driver subsystems as
well.
Beyond this, we're going to keep a close eye on the drm-misc tree,
which is exploring a move to gitlab (and working with gitlab on adding
the features they need to move over). If they get a broad maintainer
model working well in that environment it could be something we reuse
for ourselves too.
This group will also take on the responsibility of putting together
the documentation and expected patch flow for new platform/SoC
contributors. That documentation will need to evolve a bit over time
as we try out this new collaboration between maintainers.
To avoid an appearance of "ARM is taking over all architectures",
we'll rename this to just the plain "SoC tree/group", and drop ARM
from the name. As mentioned already initially we're anticipating
covering ARM (32/64-bit like before) and RISC-V platform areas in a
similar way. For other older/minor architectures that are
semi-orphaned, we might pick up code as needed when it affects us,
depending on maintainer status at the other end.
We're doing the groundwork now, and will get trees/lists/patchworks
setup for the next release cycle.
People involved so far are:
Olof Johansson (arm-soc)
Arnd Bergmann (arm-soc)
Kevin Hilman (arm-soc)
Mike Turquette (clk)
Stephen Boyd (clk)
Linus Walleij (pinctrl + more)
Mike Brown (gpio/regmap + more)
Thanks!
-Olof (on behalf of the group)
On Tue, Nov 6, 2018 at 2:16 PM Olof Johansson <[email protected]> wrote:
> Mike Brown (gpio/regmap + more)
_Obviously_ Mark Brown, not Mike. D'oh.
-Olof
Hi Olof,
On Wednesday, 7 November 2018 00:16:27 EET Olof Johansson wrote:
> Hi KS organizers (and others),
>
> This is a late topic proposal, hopefully there is still time on the agenda.
>
> We’ve recently been discussing some maintainer model changes as
> described below, and would like a slot to discuss the idea and solicit
> feedback/comments from the others there.
>
>
> This started with Arnd and I finally being in one place at the same
> time, and talking about how we want to evolve arm-soc maintainership
> moving forward. We've been independently thinking of ways to expand
> the group and making it more self-service for everybody, but there's a
> bunch of tooling needed to make it run smoothly beyond the smaller
> group we have now.
>
> In the end, we ended up looking at it from a slightly different angle:
> Right now, when contributors show up with new platform support, the
> first hill they need to climb is figuring out how they need to carve
> up their platform among all the various maintainers, how to make sure
> they're all handshaking on keeping things stable, and get code
> submitted. It's awkward, not well documented and one of the biggest
> overheads we have on our side as well.
>
> When we started talking to other maintainers, we're also realizing
> that we are currently duplicating a lot of work. In particular, we
> often all get cc:d on patch series, so we all need to read and filter,
> and assume that other maintainers spot the right patches, etc.
>
> We have discussed a few different options, and it seems like pooling
> more of the contribution flow to a group of co-maintainers is a useful
> approach. Initially, we're considering the arm-soc platforms, clock
> drivers and pinctrl drivers, which all tend to be affected by new
> platform contributions in this way, and often end up cross-cc:d on
> everything. Additionally, the flow for successfully merging a new
> platform or SoC needs to be documented and advertised. This is true
> whether or not we change the way that maintainers coordinate amongst
> themselves, or whether or not we change the current workflow used by
> platform contributors today.
>
> So, we're planning to change things up a bit. We're starting a new
> group that pools current arm-soc, clk and pinctrl drivers and
> maintainers into one funnel. We'll set up a new mail alias for the
> maintainer group, and one shared patchwork to collect contributions.
> We still expect developers to use existing mailing lists, and we still
> expect for example ARM platform maintainers to keep their workflow of
> collecting patches for their platform like they do today. Down the
> road it might make sense to incorporate other driver subsystems as
> well.
>
> Beyond this, we're going to keep a close eye on the drm-misc tree,
> which is exploring a move to gitlab (and working with gitlab on adding
> the features they need to move over). If they get a broad maintainer
> model working well in that environment it could be something we reuse
> for ourselves too.
gitlab is an umbrella term that covers many features proposed by the product.
Are there particular features that you already think you would be interested
in, or features that you already know you wouldn't want to use ?
> This group will also take on the responsibility of putting together
> the documentation and expected patch flow for new platform/SoC
> contributors. That documentation will need to evolve a bit over time
> as we try out this new collaboration between maintainers.
>
> To avoid an appearance of "ARM is taking over all architectures",
> we'll rename this to just the plain "SoC tree/group", and drop ARM
> from the name. As mentioned already initially we're anticipating
> covering ARM (32/64-bit like before) and RISC-V platform areas in a
> similar way. For other older/minor architectures that are
> semi-orphaned, we might pick up code as needed when it affects us,
> depending on maintainer status at the other end.
>
> We're doing the groundwork now, and will get trees/lists/patchworks
> setup for the next release cycle.
>
>
> People involved so far are:
>
> Olof Johansson (arm-soc)
> Arnd Bergmann (arm-soc)
> Kevin Hilman (arm-soc)
> Mike Turquette (clk)
> Stephen Boyd (clk)
> Linus Walleij (pinctrl + more)
> Mike Brown (gpio/regmap + more)
>
>
> Thanks!
>
> -Olof (on behalf of the group)
--
Regards,
Laurent Pinchart
On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
>
> Olof Johansson (arm-soc)
> Arnd Bergmann (arm-soc)
> Kevin Hilman (arm-soc)
> Mike Turquette (clk)
> Stephen Boyd (clk)
> Linus Walleij (pinctrl + more)
> Mike Brown (gpio/regmap + more)
Could the poeple listed on this list please list potential schedule conflicts?
I'm going to assume we should avoid: Andriod uConf, RISC-V uConf,
Device Tree uConf. What are other potential conflicts. I'm going to
guess this might be "interesting" to schedule. :-)
- Ted
On Tue, Nov 6, 2018 at 3:32 PM Laurent Pinchart
<[email protected]> wrote:
>
> Hi Olof,
>
> On Wednesday, 7 November 2018 00:16:27 EET Olof Johansson wrote:
> > Hi KS organizers (and others),
> >
> > This is a late topic proposal, hopefully there is still time on the agenda.
> >
> > We’ve recently been discussing some maintainer model changes as
> > described below, and would like a slot to discuss the idea and solicit
> > feedback/comments from the others there.
> >
> >
> > This started with Arnd and I finally being in one place at the same
> > time, and talking about how we want to evolve arm-soc maintainership
> > moving forward. We've been independently thinking of ways to expand
> > the group and making it more self-service for everybody, but there's a
> > bunch of tooling needed to make it run smoothly beyond the smaller
> > group we have now.
> >
> > In the end, we ended up looking at it from a slightly different angle:
> > Right now, when contributors show up with new platform support, the
> > first hill they need to climb is figuring out how they need to carve
> > up their platform among all the various maintainers, how to make sure
> > they're all handshaking on keeping things stable, and get code
> > submitted. It's awkward, not well documented and one of the biggest
> > overheads we have on our side as well.
> >
> > When we started talking to other maintainers, we're also realizing
> > that we are currently duplicating a lot of work. In particular, we
> > often all get cc:d on patch series, so we all need to read and filter,
> > and assume that other maintainers spot the right patches, etc.
> >
> > We have discussed a few different options, and it seems like pooling
> > more of the contribution flow to a group of co-maintainers is a useful
> > approach. Initially, we're considering the arm-soc platforms, clock
> > drivers and pinctrl drivers, which all tend to be affected by new
> > platform contributions in this way, and often end up cross-cc:d on
> > everything. Additionally, the flow for successfully merging a new
> > platform or SoC needs to be documented and advertised. This is true
> > whether or not we change the way that maintainers coordinate amongst
> > themselves, or whether or not we change the current workflow used by
> > platform contributors today.
> >
> > So, we're planning to change things up a bit. We're starting a new
> > group that pools current arm-soc, clk and pinctrl drivers and
> > maintainers into one funnel. We'll set up a new mail alias for the
> > maintainer group, and one shared patchwork to collect contributions.
> > We still expect developers to use existing mailing lists, and we still
> > expect for example ARM platform maintainers to keep their workflow of
> > collecting patches for their platform like they do today. Down the
> > road it might make sense to incorporate other driver subsystems as
> > well.
> >
> > Beyond this, we're going to keep a close eye on the drm-misc tree,
> > which is exploring a move to gitlab (and working with gitlab on adding
> > the features they need to move over). If they get a broad maintainer
> > model working well in that environment it could be something we reuse
> > for ourselves too.
>
> gitlab is an umbrella term that covers many features proposed by the product.
> Are there particular features that you already think you would be interested
> in, or features that you already know you wouldn't want to use ?
To be honest, I haven't looked closely yet and I'm looking forward to
learning about what the DRM plans are during LPC.
-Olof
On Wed, Nov 7, 2018 at 9:17 AM Theodore Y. Ts'o <[email protected]> wrote:
>
> On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
> >
> > Olof Johansson (arm-soc)
> > Arnd Bergmann (arm-soc)
> > Kevin Hilman (arm-soc)
> > Mike Turquette (clk)
> > Stephen Boyd (clk)
> > Linus Walleij (pinctrl + more)
> > Mike Brown (gpio/regmap + more)
>
> Could the poeple listed on this list please list potential schedule conflicts?
>
> I'm going to assume we should avoid: Andriod uConf, RISC-V uConf,
> Device Tree uConf. What are other potential conflicts. I'm going to
> guess this might be "interesting" to schedule. :-)
Yeah, apologies for adding a bunch of cross-coordination this late too.
It's likely going to be conflict-ridden no matter what we do. RISC-V
and DT are the main conflicts, Android probably has a bit less.
Tuesday afternoon looks least conflict-y when I squint at the
schedule, or Thursday afternoon (but ideally not overlapping with
Daniel's DRM/gitlab session).
-Olof
On Wed, Nov 7, 2018 at 9:35 AM Olof Johansson <[email protected]> wrote:
>
> On Wed, Nov 7, 2018 at 9:17 AM Theodore Y. Ts'o <[email protected]> wrote:
> >
> > On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
> > >
> > > Olof Johansson (arm-soc)
> > > Arnd Bergmann (arm-soc)
> > > Kevin Hilman (arm-soc)
> > > Mike Turquette (clk)
> > > Stephen Boyd (clk)
> > > Linus Walleij (pinctrl + more)
> > > Mike Brown (gpio/regmap + more)
> >
> > Could the poeple listed on this list please list potential schedule conflicts?
> >
> > I'm going to assume we should avoid: Andriod uConf, RISC-V uConf,
> > Device Tree uConf. What are other potential conflicts. I'm going to
> > guess this might be "interesting" to schedule. :-)
>
> Yeah, apologies for adding a bunch of cross-coordination this late too.
>
> It's likely going to be conflict-ridden no matter what we do. RISC-V
> and DT are the main conflicts, Android probably has a bit less.
>
> Tuesday afternoon looks least conflict-y when I squint at the
> schedule, or Thursday afternoon (but ideally not overlapping with
> Daniel's DRM/gitlab session).
Ted,
Can we have 3pm-3:30pm on Thursday? It seems relatively low on
embedded-related conflicts and at 3 people would have time to migrate
from Daniel Vetter's gitlab talk if needed.
-Olof
On Wed, Nov 07, 2018 at 09:35:09AM -0800, Olof Johansson wrote:
>
> Tuesday afternoon looks least conflict-y when I squint at the
> schedule, or Thursday afternoon (but ideally not overlapping with
> Daniel's DRM/gitlab session).
I've posted a draft schedule, so why don't we move the conversation
about scheduling there. I see a number of options that might work:
Tuesday immediately after lunch (2:00pm), or the last session before
the TAB elections (4:45pm), and on Thursday maybe at 2:45pm?
- Ted
On Tue, Nov 6, 2018 at 4:17 PM Olof Johansson <[email protected]> wrote:
>
> Hi KS organizers (and others),
>
> This is a late topic proposal, hopefully there is still time on the agenda.
>
> We’ve recently been discussing some maintainer model changes as
> described below, and would like a slot to discuss the idea and solicit
> feedback/comments from the others there.
>
>
> This started with Arnd and I finally being in one place at the same
> time, and talking about how we want to evolve arm-soc maintainership
> moving forward. We've been independently thinking of ways to expand
> the group and making it more self-service for everybody, but there's a
> bunch of tooling needed to make it run smoothly beyond the smaller
> group we have now.
>
> In the end, we ended up looking at it from a slightly different angle:
> Right now, when contributors show up with new platform support, the
> first hill they need to climb is figuring out how they need to carve
> up their platform among all the various maintainers, how to make sure
> they're all handshaking on keeping things stable, and get code
> submitted. It's awkward, not well documented and one of the biggest
> overheads we have on our side as well.
>
> When we started talking to other maintainers, we're also realizing
> that we are currently duplicating a lot of work. In particular, we
> often all get cc:d on patch series, so we all need to read and filter,
> and assume that other maintainers spot the right patches, etc.
>
> We have discussed a few different options, and it seems like pooling
> more of the contribution flow to a group of co-maintainers is a useful
> approach. Initially, we're considering the arm-soc platforms, clock
> drivers and pinctrl drivers, which all tend to be affected by new
> platform contributions in this way, and often end up cross-cc:d on
> everything. Additionally, the flow for successfully merging a new
> platform or SoC needs to be documented and advertised. This is true
> whether or not we change the way that maintainers coordinate amongst
> themselves, or whether or not we change the current workflow used by
> platform contributors today.
>
> So, we're planning to change things up a bit. We're starting a new
> group that pools current arm-soc, clk and pinctrl drivers and
> maintainers into one funnel. We'll set up a new mail alias for the
> maintainer group, and one shared patchwork to collect contributions.
> We still expect developers to use existing mailing lists, and we still
> expect for example ARM platform maintainers to keep their workflow of
> collecting patches for their platform like they do today. Down the
> road it might make sense to incorporate other driver subsystems as
> well.
Given that dts files are a large part of what goes into arm-soc, any
thoughts on changes to the process around them? I think it would be
good if dts files were a bit more decoupled from kernel code changes.
Yes, there's the issue with header dependencies to deal with. Ignoring
that for a moment, keeping the dts files somewhat separate even if
ultimately in the same tree and the same maintainers would be
beneficial both for perception and to be able to do validation
separately. And if we do ever move things out of the kernel tree, then
it's less of a work-flow change. And I'm happy to help out here in
whatever way I can.
> Beyond this, we're going to keep a close eye on the drm-misc tree,
> which is exploring a move to gitlab (and working with gitlab on adding
> the features they need to move over). If they get a broad maintainer
> model working well in that environment it could be something we reuse
> for ourselves too.
AIUI for drm-misc, a major goal there is to have more automated checks
fed back to submitters which doesn't necessarily have anything to do
with maintainers. That's something I want to get in front of for DT
schema so we're not fixing things after we've accepted them. So I've
been experimenting with gitlab CI and integration with patchwork a bit
recently. I have gitlab CI running some tests on binding patches
(checkpatch and schema validation), attaching the results to the DT
patchwork instance, and updating the patch state. Here is an example
patch[1], my patchwork related scripts are here[2], and the CI job is
here[3].
Rob
[1] https://patchwork.ozlabs.org/patch/979613/
[2] https://gitlab.com/robherring/pw-utils
[3] https://gitlab.com/robherring/linux/-/jobs
On Wed, Nov 07, 2018 at 10:47:24AM -0800, Olof Johansson wrote:
>
> Can we have 3pm-3:30pm on Thursday? It seems relatively low on
> embedded-related conflicts and at 3 people would have time to migrate
> from Daniel Vetter's gitlab talk if needed.
I'd really like to keep the slots all 45 minutes, aligned with the LPC
referreed paper track, since that's what most MC runners were also
strongly encouraged to do. (Although to be fair, it looks like most
of the MC runners haven't really stuck with that.)
The rooms are all fairly close to one another, and if you want to wait
a few minutes pack up and move next door or across the hall, that's
fine. But it's going to be a lot simpler of we tell people that the
official starting time is 2:45pm.
- Ted
On Wed, Nov 7, 2018 at 12:33 PM Theodore Y. Ts'o <[email protected]> wrote:
>
> On Wed, Nov 07, 2018 at 10:47:24AM -0800, Olof Johansson wrote:
> >
> > Can we have 3pm-3:30pm on Thursday? It seems relatively low on
> > embedded-related conflicts and at 3 people would have time to migrate
> > from Daniel Vetter's gitlab talk if needed.
>
> I'd really like to keep the slots all 45 minutes, aligned with the LPC
> referreed paper track, since that's what most MC runners were also
> strongly encouraged to do. (Although to be fair, it looks like most
> of the MC runners haven't really stuck with that.)
>
> The rooms are all fairly close to one another, and if you want to wait
> a few minutes pack up and move next door or across the hall, that's
> fine. But it's going to be a lot simpler of we tell people that the
> official starting time is 2:45pm.
Thanks, we can definitely work with that and just start a few minutes
late if there's a lot of movement between the rooms.
(Previous email seems to have crossed in compose/flight, happy to move
to the other thread but it seems like we're maybe mostly done?)
-Olof
On Wed, Nov 7, 2018 at 11:45 AM Rob Herring <[email protected]> wrote:
>
> On Tue, Nov 6, 2018 at 4:17 PM Olof Johansson <[email protected]> wrote:
> >
> > Hi KS organizers (and others),
> >
> > This is a late topic proposal, hopefully there is still time on the agenda.
> >
> > We’ve recently been discussing some maintainer model changes as
> > described below, and would like a slot to discuss the idea and solicit
> > feedback/comments from the others there.
> >
> >
> > This started with Arnd and I finally being in one place at the same
> > time, and talking about how we want to evolve arm-soc maintainership
> > moving forward. We've been independently thinking of ways to expand
> > the group and making it more self-service for everybody, but there's a
> > bunch of tooling needed to make it run smoothly beyond the smaller
> > group we have now.
> >
> > In the end, we ended up looking at it from a slightly different angle:
> > Right now, when contributors show up with new platform support, the
> > first hill they need to climb is figuring out how they need to carve
> > up their platform among all the various maintainers, how to make sure
> > they're all handshaking on keeping things stable, and get code
> > submitted. It's awkward, not well documented and one of the biggest
> > overheads we have on our side as well.
> >
> > When we started talking to other maintainers, we're also realizing
> > that we are currently duplicating a lot of work. In particular, we
> > often all get cc:d on patch series, so we all need to read and filter,
> > and assume that other maintainers spot the right patches, etc.
> >
> > We have discussed a few different options, and it seems like pooling
> > more of the contribution flow to a group of co-maintainers is a useful
> > approach. Initially, we're considering the arm-soc platforms, clock
> > drivers and pinctrl drivers, which all tend to be affected by new
> > platform contributions in this way, and often end up cross-cc:d on
> > everything. Additionally, the flow for successfully merging a new
> > platform or SoC needs to be documented and advertised. This is true
> > whether or not we change the way that maintainers coordinate amongst
> > themselves, or whether or not we change the current workflow used by
> > platform contributors today.
> >
> > So, we're planning to change things up a bit. We're starting a new
> > group that pools current arm-soc, clk and pinctrl drivers and
> > maintainers into one funnel. We'll set up a new mail alias for the
> > maintainer group, and one shared patchwork to collect contributions.
> > We still expect developers to use existing mailing lists, and we still
> > expect for example ARM platform maintainers to keep their workflow of
> > collecting patches for their platform like they do today. Down the
> > road it might make sense to incorporate other driver subsystems as
> > well.
>
> Given that dts files are a large part of what goes into arm-soc, any
> thoughts on changes to the process around them? I think it would be
> good if dts files were a bit more decoupled from kernel code changes.
> Yes, there's the issue with header dependencies to deal with. Ignoring
> that for a moment, keeping the dts files somewhat separate even if
> ultimately in the same tree and the same maintainers would be
> beneficial both for perception and to be able to do validation
> separately. And if we do ever move things out of the kernel tree, then
> it's less of a work-flow change. And I'm happy to help out here in
> whatever way I can.
Yeah, I think we need to find some good balance here that's not quite
established. I think there's good use in having some sort of superset
of DT bindings for a platform in-tree, maybe for a reference board or
similar that customers often create derivatives from, and then find a
good place for derivative DT contents out of tree. The same applies to
defconfigs, where I think the ARM64 approach of a superset of "can
boot everywhere" is useful, and if someone wants to create more
limited configs for their use case they would be free to do so.
> > Beyond this, we're going to keep a close eye on the drm-misc tree,
> > which is exploring a move to gitlab (and working with gitlab on adding
> > the features they need to move over). If they get a broad maintainer
> > model working well in that environment it could be something we reuse
> > for ourselves too.
>
> AIUI for drm-misc, a major goal there is to have more automated checks
> fed back to submitters which doesn't necessarily have anything to do
> with maintainers. That's something I want to get in front of for DT
> schema so we're not fixing things after we've accepted them. So I've
> been experimenting with gitlab CI and integration with patchwork a bit
> recently. I have gitlab CI running some tests on binding patches
> (checkpatch and schema validation), attaching the results to the DT
> patchwork instance, and updating the patch state. Here is an example
> patch[1], my patchwork related scripts are here[2], and the CI job is
> here[3].
That's really cool, thanks for sharing.
Having a place to collect lint/build/test results like this is
something I've been missing and it seems like patchwork is doing a
pretty good job there. One of the things that I'm getting excited
about is to have a shared place to collect all these signals before
patches are reviewed and applied (or pull requests merged) without
necessarily adding a lot of potentially noisy email generation.
-Olof
On Wed, Nov 07, 2018 at 12:17:23PM -0500, Theodore Y. Ts'o wrote:
> Could the poeple listed on this list please list potential schedule conflicts?
> I'm going to assume we should avoid: Andriod uConf, RISC-V uConf,
> Device Tree uConf. What are other potential conflicts. I'm going to
> guess this might be "interesting" to schedule. :-)
The clang BoFs, RT and testing would be bad for me. Possibly some other
stuff but I've not seen the schedule yet.