User:Maffblaster/Propositions

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 UXE 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:


 * Distribution kernel project

Some problems 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.

Current solutions
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 ( and possibly other locations).
 * New software would be needed to accomplish this possibility due to management scripts. A couple of projects
 * An interesting alternative to providing a separate
 * 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.

Todo
Lots to do in this area.

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://gitweb.gentoo.org/repo/gentoo.git/log/?qt=committer&q=zx2c4@gentoo.org - Developer template now include this "feature".

https://gitweb.gentoo.org/repo/proj/guru.git/log/?qt=committer&q=zarthurzam@gentoo.org

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.

Automagic menuconfig display in KernelBox
Currently our template takes a concerted and tedious effort in order to display options nicely. Editors have to manually format the text in the box to match the layout displayed in the kernel's menuconfig interface. It would be nice to have a template, (driven by JavaScript or PHP) that could take a kernel version and configuration options as input, then generate a beautiful configuration based on those inputs.

linux-kernel-config-generator.js

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.

Subdomains
A few more subdomains may be necessary. Right now they are only dreams.

Requested articles
Finish writing all requested articles.