User talk:Zoltanh721

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:

• 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.

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.

.... to be continued