Yocto Project Status 11 Feb. 2025 (WW07)

Yocto Project Status 11 Feb. 2025 (WW07)

[Stephen K Jolley]

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

Current Dev Position: YP 5.2 M3

Next Deadline: YP 5.2 M3 Build date 2025-03-03 - Feature Freeze

Next Team Meetings:

   -

   Bug Triage meeting Thursday Feb. 13th 7:30 am PST (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday Feb. 11th 8 am PST (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   <https://zoom.us/j/990892712>
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   YP 5.2 M2 was released
   -

   YP 5.0.7 is under review and passed QA
   -

   We are now 3 weeks from feature freeze for 5.2
   -

   The project autobuilder has upgraded the controller to buildbot 4.2
   which was tricky due to our custom plugin and changes to the framework used
   for the UI. The new UI should have the same functionality and seems faster
   and easier to use in places.
   -

   We’d like to request help to process the open github pull requests for
   openembedded-core and bitbake:
   -

      https://github.com/openembedded/openembedded-core/pulls
      -

      https://github.com/openembedded/bitbake/pulls

Having these open doesn’t look good for the projects and we can’t disable
them, some have been open for a long time. We did already clean up the poky
pull requests.

   -

   The project has agreed guidance on AI submissions:
   https://lists.yoctoproject.org/g/docs/message/6300
   -

   There are multiple occasional but annoying autobuilder failures we could
   do with help debugging/fixing, summarized by
   https://valkyrie.yocto.io/pub/non-release/abint/ :
   -

      An occasional hang for non-kvm x86/x86-64 qemu images early in boot,
      see in multiple kernels including the recent 6.12:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/28/builds/955

https://bugzilla.yoctoproject.org/show_bug.cgi?id=15463

   -

   dnf failures in where ssh appears to fail, usually on qemumips but also
   seen on qemuarm: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13674
   -

   Ongoing CDN failures
   -

   New memory allocation issues hinting we may need to scale builds back

We are open to help developing patches to help debug issue further or other
ideas on the causes and/or ways to mitigate them

   -

   The Linux Foundation published information on navigating global
   regulations and sanctions:
   https://www.linuxfoundation.org/blog/navigating-global-regulations-and-open-source-us-ofac-sanctions

Please contact TSC members if there are questions/concerns.

   -

   The gomod mirror issue in meta-openembedded continues to give failed
   builds on the autobuilder.
   -

   Gold linker support was removed from core.
   -

   Linux 6.6 was removed so we now just have the 6.12 kernel we plan to
   release YP 5.2 with.
   -

   The performance metric charts were improved to be able to show both
   commit based and time based data, allowing performance changes to be
   isolated more easily.
   -

   The triage team decided to clear out the “newcomer” bugs in bugzilla
   since the remaining ones were likely too hard without specialist knowledge.
   We’d love to see new/realist newcomer bugs being added.
   -

   The 5.2 development plans are being developed in this document:
   https://docs.google.com/document/d/1xsnN_HcaMhqg6Dn1P_19AnumDaUMQSdFZ_I4rjD830A/edit?usp=sharing

We need to continue to develop this, thanks to all who have contributed so
far!

Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: devtool, toaster, wic, oeqa,
   autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help
   is welcome in trying to better look after these components!
   -

   There is an issue open upstream with the openssl project related to
   making path relocation of openssl easier (as used in our buildtools tarball
   and SDK). We’d love assistance in moving this forward and getting some kind
   of upstream feature merged to make this easier:
   https://github.com/openssl/openssl/pull/19260
   -

   There are bugs identified as possible for newcomers to the project:
   https://wiki.yoctoproject.org/wiki/Newcomers
   -

   There are bugs that are currently unassigned for YP 5.2. See:
   https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium+_5.2_Unassigned_Enhancements/Bugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   <https://autobuilder.yocto.io/pub/non-release/patchmetrics/>
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.
   -

   Regarding bugs, even if you can’t fix a bug, submitting a failing test
   case that can reproduce the issue significantly improves the chances it
   might get fixed.
   -

   Further help on optimizing build disk usage would be most welcome.


Tracking Metrics:

   -

   WDD 2711 (last week 2704) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

      Total patches found: 1025 (last week 1029)
      -

      Patches in the Pending State: 172 (17%) [last week 173 (17%)]
      -

      https://autobuilder.yocto.io/pub/non-release/patchmetrics/


YP 5.2 Milestone Dates:

   -

   YP 5.2 M2 was released.
   -

   YP 5.2 M3 Build Date 2025-03-03
   -

   YP 5.2 M3 Release Date 2025-03-14
   -

   YP 5.2 M4 Build Date 2025-03-31
   -

   YP 5.2 M4 Release Date 2025-04-25


Upcoming dot releases:..

   -

   YP 5.0.7 is in review.
   -

   YP 4.0.25 Build Date 2025-02-17
   -

   YP 4.0.25 Release Date 2025-02-28
   -

   YP 5.1.3 Build Date 2025-02-24
   -

   YP 5.1.3 Release Date 2025-03-07
   -

   YP 5.0.8 Build Date 2025-03-10
   -

   YP 5.0.8 Release Date 2025-03-21
   -

   YP 5.1.4 Build Date 2025-03-24
   -

   YP 5.1.4 Release Date 2025-04-04
   -

   YP 4.0.26 Build Date 2025-04-07
   -

   YP 4.0.26 Release Date 2025-04-18
   -

   YP 5.0.9 Build Date 2025-04-21
   -

   YP 5.0.9 Release Date 2025-05-02
   -

   YP 4.0.27 Build Date 2025-05-19
   -

   YP 4.0.27 Release Date 2025-05-30
   -

   YP 5.0.10 Build Date 2025-06-02
   -

   YP 5.0.10 Release Date 2025-06-13
   -

   YP 4.0.28 Build Date 2025-06-30
   -

   YP 4.0.28 Release Date 2025-07-11


The Yocto Project’s technical governance is through its Technical Steering
Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at:
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this
weekly status update, let us know!]

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(    *Cell*:                (208) 244-4460

* *Email*:                 *s
<stephen.k.jolley@intel.com>jolley.yp.pm@gmail.com <jolley.yp.pm@gmail.com>*

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

Re: [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Alexander Kanavin]

On Tue, 11 Feb 2025 at 16:57, Stephen Jolley via
lists.openembedded.org
<sjolley.yp.pm=gmail.com@lists.openembedded.org> wrote:
> We’d like to request help to process the open github pull requests for openembedded-core and bitbake:
>
> https://github.com/openembedded/openembedded-core/pulls
>
> https://github.com/openembedded/bitbake/pulls
>
> Having these open doesn’t look good for the projects and we can’t disable them, some have been open for a long time. We did already clean up the poky pull requests.

I'm sorry but I have to say a couple of unpleasant things. Here goes.

The only processing I would be willing to do is mass-closing these
pull requests with a polite note to submit them according to the
official process. Otherwise this tacitly admits github as a valid way
to contribute, and we're not ready for that, and possible will never
be.

While we're at it, how were these repositories created in the first
place, and what was the plan for the pull requests they would attract?
Should we delete these repositories now?

Alex

Re: [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Richard Purdie]

On Tue, 2025-02-11 at 19:42 +0100, Alexander Kanavin via lists.openembedded.org wrote:
> On Tue, 11 Feb 2025 at 16:57, Stephen Jolley via
> lists.openembedded.org
> <sjolley.yp.pm=gmail.com@lists.openembedded.org> wrote:
> > We’d like to request help to process the open github pull requests for openembedded-core and bitbake:
> > 
> > https://github.com/openembedded/openembedded-core/pulls
> > 
> > https://github.com/openembedded/bitbake/pulls
> > 
> > Having these open doesn’t look good for the projects and we can’t disable them, some have been open for a long time. We did already clean up the poky pull requests.
> 
> I'm sorry but I have to say a couple of unpleasant things. Here goes.
> 
> The only processing I would be willing to do is mass-closing these
> pull requests with a polite note to submit them according to the
> official process. Otherwise this tacitly admits github as a valid way
> to contribute, and we're not ready for that, and possible will never
> be.

There are potentially useful bug reports and fixes buried in there and
I am reluctant to turn people away so I'd prefer to not mass close.

> While we're at it, how were these repositories created in the first
> place, and what was the plan for the pull requests they would attract?
> Should we delete these repositories now?

The repositories were added to try and share bandwidth costs, give
people easier mirrors and various other justifications. I warned
strongly about the pull request problems at the time, I was told it
would get handled and people would help and I was over reacting. Some
of the people who made those offers aren't active with the project any
more, other things just drifted with time. At one point I ended up
having to add those mirrors to my own push scripts and maintain them
because nobody else was willing and we had complaints they were not up
to date.

You used to be able to disable pull requests for six month periods, it
looks like you can no longer do that and it was a pain having to try
and remember anyway.

The bandwidth/mirror/backup benefits are valid and I'd be reluctant to
delete them as some people can only discover things through github too.
Google indexing doesn't work well with our own server.

So I guess I made my own peace with their existence. I know touching
them will make it look more like a condoned submission method but I
really don't see many good options here. Removing them is a simple easy
option but life sometimes isn't easy/simple.

Cheers,

Richard

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Le mer. 12 févr. 2025 à 00:36, Richard Purdie via lists.yoctoproject.org
<richard.purdie=linuxfoundation.org@lists.yoctoproject.org> a écrit :

> On Tue, 2025-02-11 at 19:42 +0100, Alexander Kanavin via
> lists.openembedded.org wrote:
> > On Tue, 11 Feb 2025 at 16:57, Stephen Jolley via
> > lists.openembedded.org
> > <sjolley.yp.pm=gmail.com@lists.openembedded.org> wrote:
> > > We’d like to request help to process the open github pull requests for
> openembedded-core and bitbake:
> > >
> > > https://github.com/openembedded/openembedded-core/pulls
> > >
> > > https://github.com/openembedded/bitbake/pulls
> > >
> > > Having these open doesn’t look good for the projects and we can’t
> disable them, some have been open for a long time. We did already clean up
> the poky pull requests.
> >
> > I'm sorry but I have to say a couple of unpleasant things. Here goes.
> >
> > The only processing I would be willing to do is mass-closing these
> > pull requests with a polite note to submit them according to the
> > official process. Otherwise this tacitly admits github as a valid way
> > to contribute, and we're not ready for that, and possible will never
> > be.
>
> There are potentially useful bug reports and fixes buried in there and
> I am reluctant to turn people away so I'd prefer to not mass close.
>
> > While we're at it, how were these repositories created in the first
> > place, and what was the plan for the pull requests they would attract?
> > Should we delete these repositories now?
>
> The repositories were added to try and share bandwidth costs, give
> people easier mirrors and various other justifications. I warned
> strongly about the pull request problems at the time, I was told it
> would get handled and people would help and I was over reacting. Some
> of the people who made those offers aren't active with the project any
> more, other things just drifted with time. At one point I ended up
> having to add those mirrors to my own push scripts and maintain them
> because nobody else was willing and we had complaints they were not up
> to date.
>
> You used to be able to disable pull requests for six month periods, it
> looks like you can no longer do that and it was a pain having to try
> and remember anyway.
>
> The bandwidth/mirror/backup benefits are valid and I'd be reluctant to
> delete them as some people can only discover things through github too.
> Google indexing doesn't work well with our own server.
>
> So I guess I made my own peace with their existence. I know touching
> them will make it look more like a condoned submission method but I
> really don't see many good options here. Removing them is a simple easy
> option but life sometimes isn't easy/simple.
>

We can try things to push users out of github :
* Leaving a fake PR at the top of the list with a title along the line of
"Please don't open a PR but instead go to <contributing guide link>"
* using the PR template (the text pre-filled for the new PR description) to
convey the same info
* A bot that automatically answer the PRs with a comment with the same idea
(the bot could also close the PR but that might be a bit harsh)

Regards,

Cheers,
>
> Richard
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#64775):
> https://lists.yoctoproject.org/g/yocto/message/64775
> Mute This Topic: https://lists.yoctoproject.org/mt/111128176/4316185
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
> yoann.congal@smile.fr]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Yoann Congal
Smile ECS - Tech expert

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

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Alexander Kanavin]

On Wed, 12 Feb 2025 at 09:08, Yoann Congal <yoann.congal@smile.fr> wrote:

> We can try things to push users out of github :
> * using the PR template (the text pre-filled for the new PR description) to convey the same info

I think this is the best option, and shouldn't be hard to add as it's
a standard github setting? Once we have that, I'd take a look at
what's open, but not before.

I also do dislike that all of this discussion around creating those
mirrors happened behind closed doors, at least I have no recollection
of it.

Alex

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Richard Purdie]

On Wed, 2025-02-12 at 10:38 +0100, Alexander Kanavin wrote:

> I also do dislike that all of this discussion around creating those
> mirrors happened behind closed doors, at least I have no recollection
> of it.

I don't think any of it was a secret and that isn't a fair
characterisation although I don't remember all the detail. The oldest
pull requests are from 2013 so it may have been before you were
involved with the project!

The YP github was newer than OE, mainly as we ended up having to
protect the namespace and there was pressure to match what OE had done.

Cheers,

Richard

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Richard Purdie]

On Wed, 2025-02-12 at 09:08 +0100, Yoann Congal wrote:
> Le mer. 12 févr. 2025 à 00:36, Richard Purdie via lists.yoctoproject.org <richard.purdie=linuxfoundation.org@lists.yoctoproject.org> a écrit :
> > The repositories were added to try and share bandwidth costs, give
> > people easier mirrors and various other justifications. I warned
> > strongly about the pull request problems at the time, I was told it
> > would get handled and people would help and I was over reacting. Some
> > of the people who made those offers aren't active with the project any
> > more, other things just drifted with time. At one point I ended up
> > having to add those mirrors to my own push scripts and maintain them
> > because nobody else was willing and we had complaints they were not up
> > to date.
> > 
> > You used to be able to disable pull requests for six month periods, it
> > looks like you can no longer do that and it was a pain having to try
> > and remember anyway.
> > 
> > The bandwidth/mirror/backup benefits are valid and I'd be reluctant to
> > delete them as some people can only discover things through github too.
> > Google indexing doesn't work well with our own server.
> > 
> > So I guess I made my own peace with their existence. I know touching
> > them will make it look more like a condoned submission method but I
> > really don't see many good options here. Removing them is a simple easy
> > option but life sometimes isn't easy/simple.
> 
> We can try things to push users out of github :
> * Leaving a fake PR at the top of the list with a title along the
> line of "Please don't open a PR but instead go to <contributing guide
> link>"
> * using the PR template (the text pre-filled for the new PR
> description) to convey the same info
> * A bot that automatically answer the PRs with a comment with the
> same idea (the bot could also close the PR but that might be a bit
> harsh)

If anyone has experience of setting this up I'd welcome help. The
things I did learn briefly looking yesterday are that:

* the template requires putting .git* files in the repo which is a bit
annoying

* there is a way to do it in a separate repo but that would apply to
all repos, not just oe-core and bitbake, at least from what I read

* our type of account may or may not have some of the features needed
for bots and so on

So I'm not against any of these but it could do with someone with some
experience. I can probably learn what is needed but I have time
challenges like everyone else.

There will probably be a need to maintain any bot going forward too.

Cheers,

Richard

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Le mer. 12 févr. 2025 à 10:51, Richard Purdie <
richard.purdie@linuxfoundation.org> a écrit :

> On Wed, 2025-02-12 at 09:08 +0100, Yoann Congal wrote:
> > Le mer. 12 févr. 2025 à 00:36, Richard Purdie via lists.yoctoproject.org
> <richard.purdie=linuxfoundation.org@lists.yoctoproject.org> a écrit :
> > > The repositories were added to try and share bandwidth costs, give
> > > people easier mirrors and various other justifications. I warned
> > > strongly about the pull request problems at the time, I was told it
> > > would get handled and people would help and I was over reacting. Some
> > > of the people who made those offers aren't active with the project any
> > > more, other things just drifted with time. At one point I ended up
> > > having to add those mirrors to my own push scripts and maintain them
> > > because nobody else was willing and we had complaints they were not up
> > > to date.
> > >
> > > You used to be able to disable pull requests for six month periods, it
> > > looks like you can no longer do that and it was a pain having to try
> > > and remember anyway.
> > >
> > > The bandwidth/mirror/backup benefits are valid and I'd be reluctant to
> > > delete them as some people can only discover things through github too.
> > > Google indexing doesn't work well with our own server.
> > >
> > > So I guess I made my own peace with their existence. I know touching
> > > them will make it look more like a condoned submission method but I
> > > really don't see many good options here. Removing them is a simple easy
> > > option but life sometimes isn't easy/simple.
> >
> > We can try things to push users out of github :
> > * Leaving a fake PR at the top of the list with a title along the
> > line of "Please don't open a PR but instead go to <contributing guide
> > link>"
> > * using the PR template (the text pre-filled for the new PR
> > description) to convey the same info
> > * A bot that automatically answer the PRs with a comment with the
> > same idea (the bot could also close the PR but that might be a bit
> > harsh)
>
> If anyone has experience of setting this up I'd welcome help. The
> things I did learn briefly looking yesterday are that:
>
> * the template requires putting .git* files in the repo which is a bit
> annoying
>
> * there is a way to do it in a separate repo but that would apply to
> all repos, not just oe-core and bitbake, at least from what I read
>
> * our type of account may or may not have some of the features needed
> for bots and so on
>
> So I'm not against any of these but it could do with someone with some
> experience. I can probably learn what is needed but I have time
> challenges like everyone else.
>
> There will probably be a need to maintain any bot going forward too.
>

I volunteer to setup a PoC in my repos to see what is possible given those
constraints.

I'm more experienced in Gitlab than GitHub but I should be able to
translate.

Obviously, if anyone has direct experience on that, don't hesitate to speak
up.

What kind of account does the yocto project has on GitHub?

Cheers,
>
> Richard
>
>
>
>

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

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Le mer. 12 févr. 2025 à 12:19, Yoann Congal <yoann.congal@smile.fr> a
écrit :

> Le mer. 12 févr. 2025 à 10:51, Richard Purdie <
> richard.purdie@linuxfoundation.org> a écrit :
>
>> On Wed, 2025-02-12 at 09:08 +0100, Yoann Congal wrote:
>> > Le mer. 12 févr. 2025 à 00:36, Richard Purdie via
>> lists.yoctoproject.org <richard.purdie=
>> linuxfoundation.org@lists.yoctoproject.org> a écrit :
>> > > The repositories were added to try and share bandwidth costs, give
>> > > people easier mirrors and various other justifications. I warned
>> > > strongly about the pull request problems at the time, I was told it
>> > > would get handled and people would help and I was over reacting. Some
>> > > of the people who made those offers aren't active with the project any
>> > > more, other things just drifted with time. At one point I ended up
>> > > having to add those mirrors to my own push scripts and maintain them
>> > > because nobody else was willing and we had complaints they were not up
>> > > to date.
>> > >
>> > > You used to be able to disable pull requests for six month periods, it
>> > > looks like you can no longer do that and it was a pain having to try
>> > > and remember anyway.
>> > >
>> > > The bandwidth/mirror/backup benefits are valid and I'd be reluctant to
>> > > delete them as some people can only discover things through github
>> too.
>> > > Google indexing doesn't work well with our own server.
>> > >
>> > > So I guess I made my own peace with their existence. I know touching
>> > > them will make it look more like a condoned submission method but I
>> > > really don't see many good options here. Removing them is a simple
>> easy
>> > > option but life sometimes isn't easy/simple.
>> >
>> > We can try things to push users out of github :
>> > * Leaving a fake PR at the top of the list with a title along the
>> > line of "Please don't open a PR but instead go to <contributing guide
>> > link>"
>> > * using the PR template (the text pre-filled for the new PR
>> > description) to convey the same info
>> > * A bot that automatically answer the PRs with a comment with the
>> > same idea (the bot could also close the PR but that might be a bit
>> > harsh)
>>
>> If anyone has experience of setting this up I'd welcome help. The
>> things I did learn briefly looking yesterday are that:
>>
>
I've played around a bit

* the template requires putting .git* files in the repo which is a bit
>> annoying
>>
> * there is a way to do it in a separate repo but that would apply to
>> all repos, not just oe-core and bitbake, at least from what I read
>>
>
I can confirm : You create a .github repo in your github organisation and
the templates inside will be used for every repos of the organisation.

For example: What you see when you try to create a PR :
https://github.com/yoconyptestgh/poky/pull/new/prononciation

What you can do with this: Have a default template "This project prefers
contribution via email, see contributing guide" for the whole org but repo
that want to follow github workflows (PR, issues) can override this in
their repo in a ".github/" folder. Not entirely satisfactory but better,
maybe?
NB: the vscode-bitbake repo already has it:
https://github.com/yoctoproject/vscode-bitbake/tree/staging/.github

Using "github actions" (the CI that could run on PR creation) seems
impossible without polluting our repos with a ".github/" repository.
If we accept to have a ".github/" directory, creating an action that
comments on every new PR is nearly trivial.

A single open pull request might also help github contributor understand
what the project want them to do:
https://github.com/yoconyptestgh/poky/pulls


> * our type of account may or may not have some of the features needed
>> for bots and so on
>>
>
Right now, the most clean approach I can think of is (given our
constraints):
* Selected repos in the yoctoproject github org use webhooks (available in
Free tier) to notify the creation of a PR or an issue
* We host (and maintain (!)) a service somewhere (on AB infra?) to receive
these notifications
* This service uses the github API to post a nice comment on the created
PR/issue (and can even close it).

I did not find a magic silver bullet that would solve everything (I
discovered that Gitlab is way more flexible on this subject).
I guess we need to find a compromise between what a github user sees and
the effort we are willing to put into it.

Regards,

So I'm not against any of these but it could do with someone with some
>> experience. I can probably learn what is needed but I have time
>> challenges like everyone else..
>>
>> There will probably be a need to maintain any bot going forward too.
>>
>
> I volunteer to setup a PoC in my repos to see what is possible given those
> constraints.
>
> I'm more experienced in Gitlab than GitHub but I should be able to
> translate.
>
> Obviously, if anyone has direct experience on that, don't hesitate to
> speak up.
>
> What kind of account does the yocto project has on GitHub?
>
> Cheers,
>>
>> Richard
>>
>>
>>
>>

-- 
Yoann Congal
Smile ECS - Tech expert

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

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Alexander Kanavin]

On Thu, 13 Feb 2025 at 00:04, Yoann Congal <yoann.congal@smile.fr> wrote:

> I did not find a magic silver bullet that would solve everything (I discovered that Gitlab is way more flexible on this subject).
> I guess we need to find a compromise between what a github user sees and the effort we are willing to put into it.

So as I understand, there are no 'settings' in github openembedded
organization we can tweak and everything is through repos?

Then here's the plan:
- someone with rights to manage overall
https://github.com/openembedded org creates an empty .github repo and
gives Yoann rights to manage it.
- Yoann opens pull requests to that repo, and notifies of them here
- any needed github specific tweaks to individual repos are proposed
and merged through the standard mailing list process.

Alex

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Hello,

Le jeu. 13 févr. 2025 à 09:49, Alexander Kanavin <alex.kanavin@gmail.com> a
écrit :

> On Thu, 13 Feb 2025 at 00:04, Yoann Congal <yoann.congal@smile.fr> wrote:
>
> > I did not find a magic silver bullet that would solve everything (I
> discovered that Gitlab is way more flexible on this subject).
> > I guess we need to find a compromise between what a github user sees and
> the effort we are willing to put into it.
>
> So as I understand, there are no 'settings' in github openembedded
> organization we can tweak and everything is through repos?
>
> Then here's the plan:
> - someone with rights to manage overall
> https://github.com/openembedded org creates an empty .github repo and
> gives Yoann rights to manage it.
>

To me, the https://github.com/openembedded subject is different from
https://github.com/yoctoproject/

On OE, issues are acted upon, PR merged (example
<https://github.com/openembedded/meta-openembedded/pull/931>). Even if not
recommended, from a contributor perspective, it does work. I don't know if
the situation is clear enough to set up something.

On YP, the situation is clearer, there are repos
<https://github.com/yoctoproject/vscode-bitbake> that use the github
workflow (issues/PR) and others that don't. Here, I feel that we can setup
the .github repo.

- Yoann opens pull requests to that repo, and notifies of them here
> - any needed github specific tweaks to individual repos are proposed
> and merged through the standard mailing list process.
>
> Alex
>

-- 
Yoann Congal
Smile ECS - Tech expert

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

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Richard Purdie]

On Thu, 2025-02-13 at 09:48 +0100, Alexander Kanavin wrote:
> On Thu, 13 Feb 2025 at 00:04, Yoann Congal <yoann.congal@smile.fr>
> wrote:
> 
> > I did not find a magic silver bullet that would solve everything (I
> > discovered that Gitlab is way more flexible on this subject).
> > I guess we need to find a compromise between what a github user
> > sees and the effort we are willing to put into it.
> 
> So as I understand, there are no 'settings' in github openembedded
> organization we can tweak and everything is through repos?

As I understand it.

> Then here's the plan:
> - someone with rights to manage overall
> https://github.com/openembedded org creates an empty .github repo and
> gives Yoann rights to manage it.
> - Yoann opens pull requests to that repo, and notifies of them here
> - any needed github specific tweaks to individual repos are proposed
> and merged through the standard mailing list process.

I don't think the github repo is going to work for either YP or OE
since there are repositories in both that use pull requests and we
can't have a one size fits all message. I think that means we would
have to do this with a .github directory in the repos themselves.

Also note, the global repos probably need TSC agreement. On a per repo
basis it would fall to the maintainer.

Yoann: Thanks for looking into this!

Cheers,

Richard

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Alexander Kanavin]

On Thu, 13 Feb 2025 at 10:45, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I don't think the github repo is going to work for either YP or OE
> since there are repositories in both that use pull requests and we
> can't have a one size fits all message. I think that means we would
> have to do this with a .github directory in the repos themselves.
>
> Also note, the global repos probably need TSC agreement. On a per repo
> basis it would fall to the maintainer.
>
> Yoann: Thanks for looking into this!

Alright. Then Yoann, can you propose patches specifically to these
two, with the aim of gently pushing back against new pull
requests/redirecting them to mailing list? It doesn't need to be
perfect, just a proposal (or several proposals) that we can select
from and refine.

https://github.com/openembedded/bitbake
https://github.com/openembedded/openembedded-core

Alex

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Le jeu. 13 févr. 2025 à 10:50, Alexander Kanavin <alex.kanavin@gmail.com> a
écrit :

> On Thu, 13 Feb 2025 at 10:45, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > I don't think the github repo is going to work for either YP or OE
> > since there are repositories in both that use pull requests and we
> > can't have a one size fits all message. I think that means we would
> > have to do this with a .github directory in the repos themselves.
> >
> > Also note, the global repos probably need TSC agreement. On a per repo
> > basis it would fall to the maintainer.
> >
> > Yoann: Thanks for looking into this!
>
> Alright. Then Yoann, can you propose patches specifically to these
> two, with the aim of gently pushing back against new pull
> requests/redirecting them to mailing list? It doesn't need to be
> perfect, just a proposal (or several proposals) that we can select
> from and refine.
>
> https://github.com/openembedded/bitbake
> https://github.com/openembedded/openembedded-core
>

That would mean to create a ".github/" directory in those. Are we ready to
do this?


> Alex
>


-- 
Yoann Congal
Smile ECS - Tech expert

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

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Alexander Kanavin]

On Thu, 13 Feb 2025 at 10:53, Yoann Congal <yoann.congal@smile.fr> wrote:
>> > I don't think the github repo is going to work for either YP or OE
>> > since there are repositories in both that use pull requests and we
>> > can't have a one size fits all message. I think that means we would
>> > have to do this with a .github directory in the repos themselves.

> That would mean to create a ".github/" directory in those. Are we ready to do this?

I think so. RP pretty much confirmed this just above?

Alex

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Richard Purdie]

On Thu, 2025-02-13 at 10:54 +0100, Alexander Kanavin wrote:
> On Thu, 13 Feb 2025 at 10:53, Yoann Congal <yoann.congal@smile.fr> wrote:
> > > > I don't think the github repo is going to work for either YP or OE
> > > > since there are repositories in both that use pull requests and we
> > > > can't have a one size fits all message. I think that means we would
> > > > have to do this with a .github directory in the repos themselves.
> 
> > That would mean to create a ".github/" directory in those. Are we ready 
> > to do this?
> 
> I think so. RP pretty much confirmed this just above?

I said that it was probably the only viable way we've seen so far. I'm
not happy at the idea. I've not said "yes we should" as yet.

I'm wondering if we should set up that default repo saying "no pull
requests" then ask repos that do accept them to override the message
with their own pull request file? The default repo is only used as a
fallback. Does an empty file do the right thing just to remove the
default message?

Cheers,

Richard

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Alexander Kanavin]

On Thu, 13 Feb 2025 at 11:03, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I'm wondering if we should set up that default repo saying "no pull
> requests" then ask repos that do accept them to override the message
> with their own pull request file? The default repo is only used as a
> fallback. Does an empty file do the right thing just to remove the
> default message?

I think the only repo under openembedded we need to carefully
coordinate with is https://github.com/openembedded/meta-openembedded
so let's add Khem and ensure this doesn't step on his workflows.

Alex

Re: [yocto] [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Le jeu. 13 févr. 2025 à 11:03, Richard Purdie <
richard.purdie@linuxfoundation.org> a écrit :

> On Thu, 2025-02-13 at 10:54 +0100, Alexander Kanavin wrote:
> > On Thu, 13 Feb 2025 at 10:53, Yoann Congal <yoann.congal@smile.fr>
> wrote:
> > > > > I don't think the github repo is going to work for either YP or OE
> > > > > since there are repositories in both that use pull requests and we
> > > > > can't have a one size fits all message. I think that means we would
> > > > > have to do this with a .github directory in the repos themselves.
> >
> > > That would mean to create a ".github/" directory in those. Are we
> ready
> > > to do this?
> >
> > I think so. RP pretty much confirmed this just above?
>
> I said that it was probably the only viable way we've seen so far. I'm
> not happy at the idea. I've not said "yes we should" as yet.
>
> I'm wondering if we should set up that default repo saying "no pull
> requests" then ask repos that do accept them to override the message
> with their own pull request file? The default repo is only used as a
> fallback. Does an empty file do the right thing just to remove the
> default message?
>

Just tested, it does : with an empty ".github/pull_request_template.md" a
repo following the github workflow gets the global default "Add your
description here..." template.


> Cheers,
>
> Richard
>
>
>
>
>

-- 
Yoann Congal
Smile ECS - Tech expert

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

Re: Yocto Project Status 11 Feb. 2025 (WW07)

[Justin Bronder]

On 11/02/25 23:36 +0000, Richard Purdie via lists.openembedded.org wrote:
> You used to be able to disable pull requests for six month periods, it
> looks like you can no longer do that and it was a pain having to try
> and remember anyway.

Isn't this just 'Settings -> Moderation Options -> Interaction Limits'?  It looks like you can restrict it to repository collaborators (which is a list under the repo owner's control) to 6 months.

It's also exposed on the REST API, https://docs.github.com/en/rest/interactions/repos?apiVersion=2022-11-28#set-interaction-restrictions-for-a-repository, which if you're willing to pull down the official github cli tool, gh, could go into a cron job fairly easily:

gh api -X PUT \
    /repos/openembedded/openembedded-core/interaction-limits \
    -f 'limit=collaborators_only' \
    -f 'expiry=six_months'

I obviously couldn't test in the OpenEmbedded Org, but this worked both on my personal repos and in a private (paid) organization.

-- 
Justin Bronder

Re: [OE-core] Yocto Project Status 11 Feb. 2025 (WW07)

[Yoann Congal]

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

Le jeu. 13 févr. 2025 à 20:13, Justin Bronder via lists.openembedded.org
<jsbronder=cold-front.org@lists.openembedded.org> a écrit :

> On 11/02/25 23:36 +0000, Richard Purdie via lists.openembedded.org wrote:
> > You used to be able to disable pull requests for six month periods, it
> > looks like you can no longer do that and it was a pain having to try
> > and remember anyway.
>
> Isn't this just 'Settings -> Moderation Options -> Interaction Limits'?
> It looks like you can restrict it to repository collaborators (which is a
> list under the repo owner's control) to 6 months.
>

It is! Thanks!
When creating a PR, users get a message "An owner of this repository has
limited the ability to open a pull request to users that are collaborators
on this repository."
Opening an Issue results in an "Unable to create issue." error (not nice).
and it is done on a repo basis.

I agree, this could be a sensible solution.

It's also exposed on the REST API,
> https://docs.github.com/en/rest/interactions/repos?apiVersion=2022-11-28#set-interaction-restrictions-for-a-repository,
> which if you're willing to pull down the official github cli tool, gh,
> could go into a cron job fairly easily:
>
> gh api -X PUT \
>     /repos/openembedded/openembedded-core/interaction-limits \
>     -f 'limit=collaborators_only' \
>     -f 'expiry=six_months'
>
> I obviously couldn't test in the OpenEmbedded Org, but this worked both on
> my personal repos and in a private (paid) organization.
>
-- 
> Justin Bronder
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#211364):
> https://lists.openembedded.org/g/openembedded-core/message/211364
> Mute This Topic: https://lists.openembedded.org/mt/111124663/4316185
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> yoann.congal@smile.fr]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Yoann Congal
Smile ECS - Tech expert

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