that flatpak update one can be an easy one to get help wanted on, right now it's just a dumb timer,
that flatpak update one can be an easy one to get help wanted on, right now it's just a dumb timer, it needs some nuance there
Jlike, I suspect clear linux's flatpak update timers are smarter than ours, those timers are like the very first thing I did a long time ago and they're due
RDo you mind if I ask, are you organising your project boards at the organisation level in GitHub? I do admin on GitHub almost on the daily if I can be of any help
BGood luck
Jit'd also be good to get more hands on the website if we can find them, specifically the images page/python needs love still and could be fleshed out better
Bthere's a ticket for improving flatpak timers in
configand we need to chart out the metrics on the site too, but @jeefy's been capturing the data so that should be a matter of someone generating a chart and then putting it on the markdown page
Jlinked, bummer the sidebar link thing only does pull requests
RTo link to tickets across repos I am fairly sure the project boards have to be at the organisation level, and you can select which repository have access to use each project board.
Then you can add an issue to a project board at the same time as you label it
Then you can add an issue to a project board at the same time as you label it
C@j0rge @bsherman works 
BRMight help to have a 'easy first ticket' type thing, or even a 'help wanted' tab in a project board
Rso easy place for new contributors can help with documentation PRs?
ASomething that runs a flatpak update at every login + an interval would be excellent there.
AThat sounds excellent. Yes we have an overarching organization level board, and per-repo milestones. It's disconnected from each other atm.
So if we're able to configure it so that the repos can access the organization board, that'd be perfect.
So if we're able to configure it so that the repos can access the organization board, that'd be perfect.
B1) we already have a service like this i linked the ticket into the one on the board about flatpack updates
2) the ticket i linked is about improving that (maybe what you mean)
2) the ticket i linked is about improving that (maybe what you mean)
Bit is already setup like this unless i'm mistaken
AIt wasn't an hour ago. Jorge said (here in chat) that we are unable to link to repo tickets from the organization board, when I asked why we don't have an assigned ticket to the "improve IDE integration" task on the org board.
Bi think he just fixed it
ALovely. 
BAYeah, that's great news. 
Jhttps://github.com/ublue-os/main/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22 is supposed to be doing that
Jbut we could perhaps tag better
Jyeah I fixed the access but there's not org-wide project board, to clarify, it's on the github feature backlog though.
Jlike, individual repos can have their own boards
Jand then you can have an org-wide board
Jbut you can't really do org-wide across all the repos with the nice linking yet
RGitHub does unfortunately treat linking between issues and linking from an issue to a pull request differently
Rin terms of the sidebar
RIn GitHub context (ie the API) an issue is just a PR without files, so it's weird they do it that way
Jthis is light enough for us to get better organized so I guess we'll make do
Jif we added another, probably better tool we'd fix one problem and then add another
Jbut yeah if anyone sees issues that need a
help-wanted tag it or tell me to tag it, that way when more people show up they can claim what they wantROne small suggestion since I can't create a PR for it; You could link to https://ublue.it/CONTRIBUTING/ in the org README file at the top of https://github.com/ublue-os where is directs people to join Discord
Custom Operating System images based on Fedora
GitHub
Community built OS images based on Fedora. Universal Blue has 37 repositories available. Follow their code on GitHub.
Roh wait I can create a PR for it 
Jyeah many pages around here need an update, always feel free to PR something if you think you can make it better!
RI didn't realise files were created in a
.github repoRthat seems new since I last looked
RNot sure who needs to review this, but a small update for the README on the org page on GitHub https://github.com/ublue-os/.github/pull/6
GitHub
And update to the README file for the organisation page.
Add a direct link to the Contributing documentation.
Some layout and wording changes.
Add a direct link to the Contributing documentation.
Some layout and wording changes.
Rthat updates the README displayed here https://github.com/ublue-os
J
Jtesting out CODEOWNERS
BApproved
JGitHub
Website and documentation. Contribute to ublue-os/website development by creating an account on GitHub.
JI need two more reviews here now that we've unbroken the website build, then things should get back to normal on /website
J
J@bsherman that is so cool how you have the versions and stuff in there, I don't see that on any other build
Bi'm trying to do interesting things
it's a mono repo for one, but also makes use of "resuable workflow" yaml... and i have early stage jobs to detect current/desired versions and automatically use those....
the stage you see there uses the kernel version/zfs version/coreos release/coreos stream all as key for the ZFS RPM image, so it effectively becomes a cache and doesn't need to be rebuilt all the time
it's a mono repo for one, but also makes use of "resuable workflow" yaml... and i have early stage jobs to detect current/desired versions and automatically use those....
the stage you see there uses the kernel version/zfs version/coreos release/coreos stream all as key for the ZFS RPM image, so it effectively becomes a cache and doesn't need to be rebuilt all the time
Jman, that's dope
Bit could be nicer... like, if i could detect if the changes in a PR are not related to ZFS build tooling, then i could use non-PR tags for the ZFS RPM image and save that step in a PR... as is, every PR still has to build the ZFS RPM image... so its not as fast as I'd like in that case, but it still saves on excessive builds if you have to do multiple commits against a PR, and
main