Something that runs a flatpak update at every login + an interval would be excellent there.
Something 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 want
ROne 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
mainbut thanks, yeah, i'm pretty happy with it
Bheh, not sure why THIS happened though
https://github.com/ublue-os/ucore/actions/runs/4984686741/jobs/8923913839#step:7:81
https://github.com/ublue-os/ucore/actions/runs/4984686741/jobs/8923913839#step:7:81
Jhuh
Jthat's usually during PRs where it doesn't have perms to push
Bi wonder if it's because the author isn't an org member
Joh
Jthat's probably why
Bthat's actually a nice test, if it's the reason
Jif it builds but the perms don't work I merge those in probably 90% of cases
Byeeah, in this case I know it's just the service -> quadlet migration
Jbecause you know what will catch it?
Bno build fail really possible
Jdo you know?
