Proposal: community maintained recipes in oe-core

Proposal: community maintained recipes in oe-core

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Hello all,

the current maintenance model in openembedded-core is problematic due to
lack of well-working process of finding maintainers, and replacing them
when they're no longer able to contribute. This becomes especially
frustrating when maintainers silently disappear, and perfectly fine patches
produced by Auto Upgrade Helper and sent to them via private mail go wasted.

I'm proposing that some of the recipes in oe-core - those that are known to
lack an active maintainer - would be transitioned to 'community
maintenance'. What this means is that the maintainer's email becomes the
oe-core mailing list email, and accordingly monthly upgrade patches will be
sent to the list. Then anyone with an interest in those components can pick
up the patches, polish/test them as needed and send them to oe-core for
inclusion into master/release branches. This opens up an easy path for
people to become maintainers, and also highlights what recipes suffer from
lack of attention.

Let me know,
Alex

[-- Attachment #2: Type: text/html, Size: 1138 bytes --]

Re: [Openembedded-architecture] Proposal: community maintained recipes in oe-core

[akuster]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]



On 5/2/20 4:35 AM, Alexander Kanavin wrote:
> Hello all,
>
> the current maintenance model in openembedded-core is problematic due
> to lack of well-working process of finding maintainers, and replacing
> them when they're no longer able to contribute. This becomes
> especially frustrating when maintainers silently disappear, and
> perfectly fine patches produced by Auto Upgrade Helper and sent to
> them via private mail go wasted.

Can you clarify what you mean by silently disappear.  By the time I have
time to process an update, someone else has sent the patches. 
>
> I'm proposing that some of the recipes in oe-core - those that are
> known to lack an active maintainer - would be transitioned to
> 'community maintenance'.
Define active

> What this means is that the maintainer's email becomes the oe-core
> mailing list email, and accordingly monthly upgrade patches will be
> sent to the list. Then anyone with an interest in those components can
> pick up the patches, polish/test them as needed and send them to
> oe-core for inclusion into master/release branches.

Well that is one of the problems of putting tooling into the community's
hands. It is made it easy to send updates to the list. Is not uncommon
to accept "Update" as the only  information, do you expect the submmiter
to deal with stable or the Package Maintainer?

This opens up an easy path for people to become maintainers, and also
highlights what recipes suffer from lack of attention.

I agree there should be a way to update maintainers e-main once we
determine they are not longer willing to take part in that program or
absent. I believe this an issue in general for OpenSource has had to
address over the years.
>
> Let me know,
> Alex
>
> 


[-- Attachment #2: Type: text/html, Size: 3332 bytes --]

Re: [Openembedded-architecture] Proposal: community maintained recipes in oe-core

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

On Mon, 4 May 2020 at 00:16, akuster <akuster808@gmail.com> wrote:

> the current maintenance model in openembedded-core is problematic due to
> lack of well-working process of finding maintainers, and replacing them
> when they're no longer able to contribute. This becomes especially
> frustrating when maintainers silently disappear, and perfectly fine patches
> produced by Auto Upgrade Helper and sent to them via private mail go wasted.
>
>
> Can you clarify what you mean by silently disappear.  By the time I have
> time to process an update, someone else has sent the patches.
>

That means: a) not sending any patches, despite AUH reminders, for months;
b) not otherwise active or visible on the lists. You wouldn't qualify, so
no worries.


>
> I'm proposing that some of the recipes in oe-core - those that are known
> to lack an active maintainer - would be transitioned to 'community
> maintenance'.
>
> Define active
>

The reverse of the above: sending patches OR otherwise active on the lists.


>
> Well that is one of the problems of putting tooling into the community's
> hands. It is made it easy to send updates to the list. Is not uncommon to
> accept "Update" as the only  information, do you expect the submmiter to
> deal with stable or the Package Maintainer?
>

We can certainly ask anyone who sends a patch to try and provide more
information about the update. The reason I'm not doing it is that I have
too many updates to handle; but someone with only a few recipes should be
better able to find time for it.


>
> I agree there should be a way to update maintainers e-main once we
> determine they are not longer willing to take part in that program or
> absent. I believe this an issue in general for OpenSource has had to
> address over the years.
>

My plan is to experiment with this for the python3* recipes in oe-core for
a start: they've been bouncing between various people over the past couple
of years, but no active maintainer has emerged.

Alex

[-- Attachment #2: Type: text/html, Size: 3281 bytes --]

Re: [OE-core] [Openembedded-architecture] Proposal: community maintained recipes in oe-core

[Jens Rehsack]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]



> Am 05.05.2020 um 13:48 schrieb Alexander Kanavin <alex.kanavin@gmail.com>:
> 
> On Mon, 4 May 2020 at 00:16, akuster <akuster808@gmail.com> wrote:
> the current maintenance model in openembedded-core is problematic due to lack of well-working process of finding maintainers, and replacing them when they're no longer able to contribute. This becomes especially frustrating when maintainers silently disappear, and perfectly fine patches produced by Auto Upgrade Helper and sent to them via private mail go wasted.
> 
> Can you clarify what you mean by silently disappear.  By the time I have time to process an update, someone else has sent the patches.
> 
> That means: a) not sending any patches, despite AUH reminders, for months; b) not otherwise active or visible on the lists. You wouldn't qualify, so no worries.

Jepp - happens often: people switch responsibilities / projects and even with best intensions to spend effort in spare time more and more things fall down.

>> 
>> I'm proposing that some of the recipes in oe-core - those that are known to lack an active maintainer - would be transitioned to 'community maintenance'.
> Define active
> 
> The reverse of the above: sending patches OR otherwise active on the lists.
> 
> 
> Well that is one of the problems of putting tooling into the community's hands. It is made it easy to send updates to the list. Is not uncommon to accept "Update" as the only  information, do you expect the submmiter to deal with stable or the Package Maintainer?
> 
> We can certainly ask anyone who sends a patch to try and provide more information about the update. The reason I'm not doing it is that I have too many updates to handle; but someone with only a few recipes should be better able to find time for it.

The process should be better described and developed than "sending the patch again" ...

> I agree there should be a way to update maintainers e-main once we determine they are not longer willing to take part in that program or absent. I believe this an issue in general for OpenSource has had to address over the years.
> 
> My plan is to experiment with this for the python3* recipes in oe-core for a start: they've been bouncing between various people over the past couple of years, but no active maintainer has emerged.

I'd like to see 'non-systemd init' in, either :)

Cheers
--
Jens Rehsack - rehsack@gmail.com


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [OE-core] [Openembedded-architecture] Proposal: community maintained recipes in oe-core

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Thu, 7 May 2020 at 14:38, Jens Rehsack <rehsack@gmail.com> wrote:

> > I agree there should be a way to update maintainers e-main once we
> determine they are not longer willing to take part in that program or
> absent. I believe this an issue in general for OpenSource has had to
> address over the years.
> >
> > My plan is to experiment with this for the python3* recipes in oe-core
> for a start: they've been bouncing between various people over the past
> couple of years, but no active maintainer has emerged.
>
> I'd like to see 'non-systemd init' in, either :)
>

On a technical level this means updating maintainers.inc entries to list
oe-core list as the email address; the next AUH round (in a week or so)
will go as usual (because it's the first post-release one), and depending
on how maintainers react, and who hasn't sent anything at all for a long
time, I will propose something specific.

Alex

[-- Attachment #2: Type: text/html, Size: 1259 bytes --]

Re: [OE-core] [Openembedded-architecture] Proposal: community maintained recipes in oe-core

[Richard Purdie]

On Thu, 2020-05-07 at 15:24 +0200, Alexander Kanavin wrote:
> On Thu, 7 May 2020 at 14:38, Jens Rehsack <rehsack@gmail.com> wrote:
> > > I agree there should be a way to update maintainers e-main once
> > we determine they are not longer willing to take part in that
> > program or absent. I believe this an issue in general for
> > OpenSource has had to address over the years.
> > > 
> > > My plan is to experiment with this for the python3* recipes in
> > oe-core for a start: they've been bouncing between various people
> > over the past couple of years, but no active maintainer has
> > emerged.
> > 
> > I'd like to see 'non-systemd init' in, either :)
> 
> On a technical level this means updating maintainers.inc entries to
> list oe-core list as the email address; the next AUH round (in a week
> or so) will go as usual (because it's the first post-release one),
> and depending on how maintainers react, and who hasn't sent anything
> at all for a long time, I will propose something specific.

I agree we do need to do something and it was briefly discussed by the
YP TSC who basically agreed we need to tweak things.

Firstly though, we could do with digging out Ross' original emails and
properly documenting "maintainers" on the wiki. I thought we'd done
that but none of us could find it with a quick search which is bad if
it does exist.

Is anyone willing to summarise the current process on the wiki based on
those emails? (or point at the page if it does exist!)

Cheers,

Richard