Le mer. 12 févr. 2025 à 12:19, Yoann Congal <[email protected]> a écrit :
> Le mer. 12 févr. 2025 à 10:51, Richard Purdie < > [email protected]> 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= >> [email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211282): https://lists.openembedded.org/g/openembedded-core/message/211282 Mute This Topic: https://lists.openembedded.org/mt/111139348/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
