> Here are the notes from the meeting today and then some. If you would > like to elaborate or ask questions please do so here. > > Our new hardware needs (HDD space, SSDs) > > * > > Fabio handling this? Is he aware of everything we need? > > > > Bugzilla improvements > > * > > Too complicated, too many choices, not all correct > > * > > Requesting a package ALWAYS goes to SCR, but shouldn’t > > * > > No easy way to differentiate between bugs. > > * > > Possibility of bug bankruptcy? > > > > Communication with our community > > * > > Blog team of 2-3 people? > > * > > Verification of article before submissions > > * > > Covering changes, releases, growth, and even general linux battles > Sabayon faces > > * > > At least once > > * > > Mudler has credentials/can invite. > > * > > > https://github.com/Sabayon/sabayon-website-next/tree/master/content/article > > * > > > https://github.com/Sabayon/sabayon-website-next/tree/master/content/release > > * > > Open to the public for articles, should probably have a wiki page > for this. > > > > Libav vs ffmpeg > > * > > Mudler will speak with libav team next week. We should obtain > required info for final decision upon next meeting. > > > > ARM support > > * > > No ARM downloads link in download page (microchip icon from > fontawesome 4.7) > > * > > ARM only shows up under stable (unless RPi) > > * > > Notice: ARM images are minimal might be useful > > * > > Website must remain mobile support compliant > > > > GCC upgrade (status, branch, SLO?) > > * > > Branching may result in user unfriendly issues. > > * > > Hopping branches needs to be automated and somewhat noob friendly. > > * > > Chroot snapshot, then bump GCC and recompile all as opposed to > branching? > > * > > Use of eit status to tell what is recompiled vs what is not. > > * > > Need to complete core updates before freezing for GCC > > > > Security team possibilities > > * > > Need more manpower to prevent slow downs of dev process. > > * > > Team would actively search and find security issues and push on > upstream or gentoo for patches. > Sabayon is a downstream distribution of Gentoo and responsibility of tracking security problems lies primarily on the latter. Focus of the Sabayon team I believe should be on tracking issues from Gentoo and reacting on them from the Sabayon side. Of course, an issue that we get to know should be communicated to Gentoo, but in my opinion doing what any regular user could do, i.e. file a bug on their bug tracker is enough. Or when so inclined, one could join the Gentoo security team. Some "active upstream research" would make sense only for the few additional packages in the overlay. > > * > > Is the team actually necessary? Last known issue was > > https://github.com/Sabayon/for-gentoo/commit/8858b6ce02931112fccd87e7819042df95f29d1f > > * > > Are issues currently discovered by happenstance or active searching? > The most critical issues are handled very quickly, but for the rest, I'm not aware of any active research other than what I do periodically, using the Gentoo bug tracker. (Side note: GLSA is slow and not made for unstable packages, so tracking bugs on the Bugzilla seems to be the only way. Tracking new bugs and updates to them requires discipline, or some kind of a good organisation if done by more people. I can share my techniques.)
Another thing that helps is just keeping packages updated; in fact, it is quite rare for me to discover an old version with a security problem when I do my checks. (But when the checks are done, updates can be provided faster.) Either way, this can still be improved. This paragraph explains why I didn't like the point above about finding issues somewhere. Let's first look for them in Gentoo. > > * > > U2F capabilities? (yubikey assisted login PAM etc) > > > > Entropy auto updater > > * > > Can we not release this to sabayonlinux.org > <http://sabayonlinux.org> repo? > > * > > Can it not include auto branch hopping upon branch completion? > > * > > Can we add auto-updater feature to magneto? > > * > > Keep as systemd service to allow compat with minimal distros. > > * > > Have Rigo remind users of updating config files. > > > > Entropy autoremove function > > * > > Enlik and dontpanic? > Equo has the "unused" command. The first step to making it more useful would be the improvement from the open PR: https://github.com/Sabayon/entropy/pull/36. Would this be enough? Maybe there should be also a one time conversion like "all of these packages are user-installed," to kind of fix the currently wrong recorded status (after this is merged)… > > * > > tool will give packages that have no reverse deps and uninstall > them if not needed. > > > > BTRFS Anaconda installer support? > > * > > BTRFS is bootable from GRUB, snapshot support etc is nice. ZFS > isn’t bootable yet. > > > > Virtualization and containers (dockers, OMVF, etc) > > * > > OMVF support needed. (virt-manager “UEFI not found”) > > * > > VMs should be more turnkey for server deploys > > * > > Docker simplification for administration? http://panamax.io/, > https://portainer.io/, https://github.com/francescou/docker-compose-ui > > * > > Proxmox showing sabayon docker as option in list > > > > Clearing up questions of entropy development. > > * > > Enlik? > What is the question? :)
