Here I have listed improvement propositions I believe will improve the over all look and feel of the wiki. Some of these ideas may eventually get posted on the Discussions article, but for now these ideas will stay here. If a proposition is accepted and the work required for the change has been done I will cross it off this list.
Gentoo User Experience Enhancement project
I would like to start a new project with the specific interest in providing user experience enhancements for operating and maintaining Gentoo systems. This update could be entitled GUXE project, or Gentoo User Experience Enhancement project.
Due to Gentoo being a rolling-release style distribution with no yearly or semi-yearly release, which is the case for other FOSS operating system distributions and/or closed source operating systems such as Microsoft Windows, delaying too long between updates tends to increase the complexity of updates.
Project efforts that have greatly aided the user experience:
Some problems with updates defined
Undeniably, one of the most difficult parts of using and maintaining Gentoo is updating old systems. As an active user of many Gentoo systems, updates should be easier to approach and take less time. Over the years, I've found updates do not Just Work TM when the Gentoo ebuild repository falls greatly out of date - it causes a cascade effect into the majority of usability issues.
For example, one of my systems that has been offline has not synced in almost a year and a half. In this instance, there was not an EAPI change, but when a system is two or more EAPI changes behind, Portage doesn't understand the new EAPI and will bail out providing updates. The only workaround to this issue of which I am aware is to manually perform an emergency rescue update to Portage by pulling down the source, setting up a 'rescue' environment, and resolving blockers, unsnarling USE flag changes, and usually unmerging packages until Portage can calculate an update path that works.
I usually end up cutting much of my system's current configuration in order to get back to a system configuration that mostly aligns with USE defaults in order for Portage to take over automatic updates.
To prove my point, it would be work keeping some release media around from staged annual or semi-annual checkpoints from 1 to 5 years old, and then attempt to update them. I have some disk images that, after being scrubbed from personal data, could be used for some Gentoo update olympics. Even seasoned developers would have a difficult time without resorting to custom checkouts of gentoo.git, performing some updates, then checking out a later state and repeating the same process until their system is fully up to date.
Systems that are falling behind will provide a minor notification when emerging software.
TODO: Link to the code in Portage that will display this warning.
An enhancement would be to provide a customizable definition file so that package manager could provide warning levels levels to show the notification when it calculates system has fallen behind. It should also log these details to the syslog so that SIEMs and/or environments with system log and event management can be alerted of out of date software.
Solutions via mitigations: leveraging existing software and minor configuration changes
A few considerations should be made for solutions that do not require new software.
- Automated updates via cron jobs or timers.
- Provides updates to ebuild repositories regularly.
- Proposes updates to @system, @world, or custom software sets, however will likely require a wrapper script to merge USE configuration changes.
- Binpkg hosts could provide a fielded set supported update packages. As long as the system administrator has not branched too far away from default USE flags, this method could provide a long-term solution for updates and therefore minimize update maintenance.
Solutions via new software: new software proposals, major configuration changes, or new project efforts
- A/B partition targets for system critical files (/usr and possibly other locations).
- A new software mechanism would be needed to accomplish this possibility. This would be necessary to management the installation of software into the B partition before a system reboot, then manage the fallback to the A partition if the B partition fails to boot properly. A couple of Linux distributions may already use this approach... CoreOS may have done so historically.
- Formalized annual, semi-annual, or quarterly releases with clear, tested upgrade paths. This would require a momentous amount of work - and will likely be ruled out for a few reasons:
- It works against the rolling release model
- It would require a large amount of setup and continual automated testing in order to sanity/smoke check that upgrade paths are working as expected.
- It may break the ability for the OS to continue on the rolling release model, unless it is combined with A/B partitions.
- Bootstrapping from the historical HEAD, up to the present HEAD.
- This approach has software and infrastructure prerequisites:
- Git must be used as the repository sync system so that calculations can be performed to bootstrap an old system.
- Historical distfiles will need to be available in a manner that parallels the commit timestamp.
- A new management utility would be necessary to perform the bootstrap work, adjustable from a daily/weekly/monthly/quarterly/biannually/yearly calculation... This would be essentially an extension of the current QA scripts, but would try to update in larger increments. If an emerge fails fails after checking out a month's worth of commits, it could bicept two weeks worth of commits and try again, then a single week, then 3 days, etc. until the emerge succeeds.
- This approach has software and infrastructure prerequisites:
Additional user experience enhancement ideas
Lots to do in this area:
- Distributing scripts as part of eselect news to ease system maintenance.
- Many repository news items instruct the end users to follow a set of upgrade, downgrade, or other administrative instructions in order to maintain their systems. wouldn't it be near if some basic bash or python compatible scripts could be distributed alongside the news updates to automate the steps typically suggested to be manually performed?
- This would likely result in some extra dependency and state checking as part of the eselect framework, like analyzing which repository news items are in a completed or not started state. The framework could work down the list released news items.
- Once the system's software state is ready for a new layout or change, the user could execute the update script via eselect by something like:
- eselect news execute 1
Add commit history for gentoo.git or guru.git to developer and user templates
Add a checkbox to
developer and user forms/templates that enable the account to link to the below URL. Provides a convenient link to commit history and allows our community to more easily track the involvement and development of a certain (muh favorite!!!) developer in ::gentoo and/or ::guru ebuild repositories.
https://email@example.com - Developer template now include this "feature".
For developers, this was implemented as an extension to "Package developer" checkbox for the developer template, since email address is a required attribute for developers and the committer will always have an email address.
Copy to clipboard for command/code templates
We need to have a template for quickly and easily copying text to the clipboard. Clipboard.js should provide these kinds of capabilities without the need for Flash, which is excellent... it would be extremely useful for copying article blueprints, commands, or scripts directly from the wiki to be pasted into a terminal.
A few more subdomains may be necessary. Right now they are only dreams.
Could possibly be integrated with the https://identity.gentoo.org SSO idea
|Gentoo system bus (yes, you read that correctly!). It's just an idea, but it would be neat to have a rewards system for community members and (opt in) for developers. Something that tracks their involvement and rewards them when they do things to make Gentoo a better place. For example, once a user creates three bugs that have been marked as "confirmed", a trigger will fire 'rewarding' that user (if they have opted into the project). Steam has been doing this type of thing for years. I believe a reward systems (as meaningless it might be for some) will largely boost not only community involvement, but developer involvement as well. Of course, this will only be for community members/developers that "opt in" to the program.||Unknown|
|A site for watching live interviews of Gentoo developers and/or receiving video news.||GitHub (LFS)|
|https://magazine.gentoo.org||The future home of GMN?||GitHub (Jekyll)|
Finish writing all requested articles.