From Fedora Project Wiki

Thoughts about the needed changes to Fedora Infrastructure in my point of view

These thoughts are my only personal feelings about to how to achieve huge evolution in development, and contributor handling. With this structure changes I think we could be more effective, and flexible and also that feeds back to Red Hat in software QA, and contribution flow vice-versa.


Fedora: part of the contributor ecosystem structure

Mainly the distribution itself, could be the basement of the informations, and the work-flow. With the following minor and major changes we could build up the whole contribution chain. For the entry level we need the following tools - just based on METAPACKAGES:

  • Local Documentation and Messaging Management - in /home (if the user is an contributor then needs a feedback to the upper level, and markings to todo's) - to know who said what, and what was the result, what was the feedback.

When somebody currently downloads and installs Fedora, then finds only empty, non-integrated folders in their /home. This part of the system still intact. This is needed to the entry level who signing the FAS, and their role. Each role needs different type of further todo's, and documents, samples, minimal tutorials, how-to's as start-up - and it's software managed support (this feature currently missing). No one's is perfect, and we must give the opportunity to our people or up to anyone to learn the know-how (instead of hunting after the information or the process. That's why we need the next.).

  • Startup service pack - Service pack RPM's what quickly transforms our base: Community pack, Spins pack, Contributor-xx-Role pack, and Ambassador pack

1. Community type: This type of RPM could contain such virtual packages (eg. references to other packages) where the user gets the ability to use its system as social-network binded Fedora system (eg. facebook of fedora, linkedin or such). More communications tools (chat, microblogging, note taking, one-click multimedia support, driver setup, visual customisation support like wallpapers and more). This is currently made by several uncontrolled 3rd party rpm's like EasyLife.

2. Spins type: This type of virtual packages should contain the setup and their software relations. If the user calls one of it, then the RPM transforms to the wished outfit, and setup.

3. Contributor type: This type of RPM must hold such package relations what strongly depends from the chosen role. It must contain as mentioned: todo's, documents, samples, minimal tutorials as start-up when it's installed at /home folders. I could think that too, that version when we utilise more folders. Like todo folder, with small txt entries.

4. Ambassador type: This type sightly different. This RPM must hold the most crucial informations to this role, and settings, setups, scripts, templates to the CMS fedorapeople storage. With the customized LightNEasy CMS upload, the ambassador gets the ability to have easier life on road if needs anything. Reports, contacts, photos, personal swag inventory, community templates (twitter, and others), docs (presentations, pdf's, odf's), and up to anything till the quoted storage gets fully filled.

Suggestion to the descriptions, docs, mini tutorials: several automagically opening webpages, or pdf's, odf's in their browser

  • General system update flow in service packs - Systematically numbered updates makes easier to follow/revert the weekly periodical repair, and update

Yet this is an still unused packagekit option, or better said - feature. With that, I think - utilising this option - we could gain offline repair/upgrade support if you're not in front of your machine, and several customization option without wasting the storage. We have yum

  • Backup made easily - We don't really need several hunting for our apps, when we could have them easily. How? We need an yum plugin what records the installed and the picked-up apps by user. Then this list must be easily saved, restored, alltogether with the smolt profile. Why?

If we using the smolt to restore just our driver settings, along with our beloved apps (personalisation), then everybody could imagene how happy could be the user when 30 minutes later the system is ready to launch where he has left.

  • Customisation when anaconda starts - When anaconda starts, then the user has the ability to choose softwares, UI, but hardware, and drivers don't. I think here at anaconda must show the attached hardwares, recognised ones on one datasheet - and try ability after the user has accepted the license.

Here comes in again the earlier mentioned metapackage what contains the smolt profile and the apps.