Wiki Mageia

Add procedure

New page

== Reassigning packages in Maintdb ==

A user should normally take or release his/her own packages using [[Mgarepo#I_want_to_see_who_is_the_maintainer_of_a_package|mgarepo maintdb]]. But if a user has dropped off the face of the earth, or has many packages to unassign, a sysadmin can do it instead.

=== Validate the request ===

First, see this discussion about [[unresponsive_package_maintainers#Notes_for_Mass_Orphaning|unresponsive package maintainers]] and validate the request. If the packager is no longer active, the login should probably also be removed from mga-packagers (and any other active groups) and added to mga-alumni (see the [[SOP_Adding_user_to_group|separate procedure]] for doing that) in addition to dropping packages.

=== Back up the maintdb ===

The normal [https://gitweb.mageia.org/infrastructure/puppet/tree/modules/buildsystem/templates/maintdb/maintdb.bin CLI front-end to maintdb] only allows access by the user gaining or dropping maintenance and has safety checks. A mass change means manipulating the database directly, which has the potential for causing massive damage. Before making any change, download a current copy of the maintdb from https://pkgsubmit.mageia.org/data/maintdb.txt so you have something to work with if it becomes necessary to restore it later.

=== Update the Maintdb ===

To unassign a package on behalf of another user, run this command:
<pre>
sudo -u maintdb sh -c 'cat "/var/lib/maintdb/db/$1" && echo "$2" >"/var/lib/maintdb/db/$1"' x PACKAGE nobody
</pre>
where PACKAGE is the package name and nobody is the user to which the package will be assigned. The previous maintainer's ID will be displayed on success. If the package name is invalid, an error message will be displayed and no reassignment will take place. Danf

Add remove instructions

← Older revision Revision as of 22:16, 30 September 2024 Line 10: Line 10:  Then run (using your login as uid): Then run (using your login as uid):    −   [root@valstar ~]# ldapadd -H ldaps://ldap.mageia.org -D uid=blino,ou=People,dc=mageia,dc=org -W -f addusertogroup.ldif+   [root@valstar ~]# ldapadd -H ldaps://ldap.mageia.org -D uid=$USER,ou=People,dc=mageia,dc=org -W -f addusertogroup.ldif  +   += Removing user from group =  +   +In order to remove an existing user from an existing group, create a small file remove.ldif with the following contents:  +  dn: cn=<mga-groupname>,ou=Group,dc=mageia,dc=org                   +  changetype: modify  +  delete: member  +  member: uid=<user-login>,ou=People,dc=mageia,dc=org  +where ''<mga-groupname>'' is the group from which you want to remove the user, and ''<user-login>'' is the login of the user.  +   +Then run (using your login as uid):  +   +  [root@valstar ~]# ldapmodify -H ldaps://ldap.mageia.org -D uid=$USER,ou=People,dc=mageia,dc=org -W -f remove.ldif     [[Category:Sysadmin]] [[Category:Sysadmin]] Danf

‎Estonian: Marek died years ago

← Older revision Revision as of 15:44, 30 September 2024 (One intermediate revision by the same user not shown)Line 120: Line 120:  * '''Vacant''' - Team leader - * '''Vacant''' - Team leader -  * Marja van Waes (marja) marja11 [AT] freedom [DOT] nl * Marja van Waes (marja) marja11 [AT] freedom [DOT] nl −* Reinout van Schouwen - reinout [AT] gmail [DOT] com  −* Remco Rijnders (Remmy) - remco@webconquest.com   * Marc Laan (marchugo) - laan puntje marc op gmail * Marc Laan (marchugo) - laan puntje marc op gmail    Line 132: Line 130:  * Bram Verdoodt (Bram0s) - bram.verdoodt[AT] gmail [DOT] com * Bram Verdoodt (Bram0s) - bram.verdoodt[AT] gmail [DOT] com  * Rob Vriens (rovri) - rob DOT vriens AT gmail DOT com * Rob Vriens (rovri) - rob DOT vriens AT gmail DOT com  +* Reinout van Schouwen - reinout [AT] gmail [DOT] com  +* Remco Rijnders (Remmy) - remco@webconquest.com     = English = = English = Line 142: Line 142:     = Estonian = = Estonian = −* '''Marek Laane (mareklaane)''' - bald AT smail DOT ee - Estonian translation coordinator, commit rights+   +* Vacant  +* In warm memory of '''Marek Laane (mareklaane)''' - who used to be the Estonian translation coordinator     = French = = French = Marja

‎Translation teams: Update the leaders

← Older revision Revision as of 14:46, 30 September 2024 Line 21: Line 21:  == Translation teams == == Translation teams ==    −The current Mageia internationalisation team representatives are Rémi Verschelde (Akien on IRC) and Yuri Chornoivan (yurchor).+The current Mageia internationalisation team representatives are Yuri Chornoivan (yurchor) and Filip Komar (filip).  Each per-language subteam has its own representatives who should attend the i18n team meetings (if possible) and coordinate the workflow of their subteam. These representatives are shown in bold on the [[I18n teams]] listing page.<br> Each per-language subteam has its own representatives who should attend the i18n team meetings (if possible) and coordinate the workflow of their subteam. These representatives are shown in bold on the [[I18n teams]] listing page.<br>    Line 32: Line 32:     (Outdated list: [[Archive:Initially registered i18n people|People having registered for translations]])}} (Outdated list: [[Archive:Initially registered i18n people|People having registered for translations]])}} −  −      == Translation Statistics and reports == == Translation Statistics and reports == Marja

‎About packaging: fix bold everything

← Older revision Revision as of 18:52, 29 September 2024 Line 63: Line 63:  We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one.   We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one.    ==About packaging== ==About packaging== −==='''Change to a state of the art, easy to use, powerfull and efficient build system===+===Change to a state of the art, easy to use, powerfull and efficient build system=== −Like https://openbuildservice.org/.'''+Like https://openbuildservice.org/.     Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Psyca

typo

← Older revision Revision as of 17:56, 29 September 2024 (One intermediate revision by the same user not shown)Line 42: Line 42:  == Hoe valideert u een backport == == Hoe valideert u een backport ==    −Het proces voor het valideren van een backport is vergelijkbaar met dat voor [[QA proces voor het valideren van herzieningen (updates)-nl|het valideren van updates]], maar het testen is niet zo gedetailleerd. Als u de backport hebt verpakt, kunt u ook certificeren dat u deze op één architectuur hebt getest en dat telt mee voor de validatie. De persoon die het pakket aanvraagt ​​om te worden gebackporteerd, moet zoveel mogelijk bij het testen worden betrokken.+Het proces voor het valideren van een backport is vergelijkbaar met dat voor [[QA proces voor het valideren van updates-nl|het valideren van updates]], maar het testen is niet zo gedetailleerd. Als u de backport hebt verpakt, kunt u ook certificeren dat u deze op één architectuur hebt getest en dat telt mee voor de validatie. De persoon die het pakket aanvraagt ​​om te worden gebackporteerd, moet zoveel mogelijk bij het testen worden betrokken.     === Controlelijst beleid === === Controlelijst beleid === Line 120: Line 120:     # '''Schrijf een validatiebericht''' om mensen te laten weten dat de update correct is getest op beide architecturen en, indien nodig, alle releases.<br/><br/> # '''Schrijf een validatiebericht''' om mensen te laten weten dat de update correct is getest op beide architecturen en, indien nodig, alle releases.<br/><br/> −# '''Voeg een lijst toe van de geteste/goedgekeurde Source RPM's''' (SRPM's). Voor meer informatie over het vinden van de SRPM voor een pakket, zie de pagina [[How_to_find_a_source_RPM|Hoe vind ik een Sourde RPM]].<br/><br/>+# '''Voeg een lijst toe van de geteste/goedgekeurde Source RPM's''' (SRPM's). Voor meer informatie over het vinden van de SRPM voor een pakket, zie de pagina [[How_to_find_a_source_RPM|Hoe vind ik een Source RPM]].<br/><br/>  # '''Voeg het advies (Advisory) toe, herschrijf deze indien nodig'''. De Advisory is een beschrijving die aan gebruikers wordt getoond als reden voor de backport, dus hij moet duidelijk zijn. Vraag de packager om de Advisory te verstrekken als deze ontbreekt, of als u niet weet wat u moet schrijven. Als de Advisory al wel is gepost en de huidige SRPM-versies toont, kopieer die tekst dan in uw opmerkingen of link gewoon naar het relevante commentaar. Bugzilla begrijpt woorden als ''bug 6334'' en ''commentaar 3'' en zal ze automatisch omzetten in links. Bijv. ''Zie commentaar 3 voor advies en SRPM''.<br/><br/> # '''Voeg het advies (Advisory) toe, herschrijf deze indien nodig'''. De Advisory is een beschrijving die aan gebruikers wordt getoond als reden voor de backport, dus hij moet duidelijk zijn. Vraag de packager om de Advisory te verstrekken als deze ontbreekt, of als u niet weet wat u moet schrijven. Als de Advisory al wel is gepost en de huidige SRPM-versies toont, kopieer die tekst dan in uw opmerkingen of link gewoon naar het relevante commentaar. Bugzilla begrijpt woorden als ''bug 6334'' en ''commentaar 3'' en zal ze automatisch omzetten in links. Bijv. ''Zie commentaar 3 voor advies en SRPM''.<br/><br/>  # '''Voeg een bericht toe voor het Sysadmin Team, waarin u vraagt ​​om de pakketten te pushen'''. Pushen betekent het verplaatsen van de pakketten van het ene medium naar het andere. Voor QA betekent dit dat de sysadmins worden gevraagd om de SRPM te pushen van Backports Testing-media naar de bijbehorende Backports-media. Alle pakketten die in de SRPM zitten worden gepusht. De backport zal dan beschikbaar zijn voor alle Mageia-gebruikers als een gevalideerde backport.<br/><br/>Een voorbeeld van het type opmerking dat u kunt achterlaten:<br/><br/>''------------------------------------------------------------------------------------------<br/>Update validated. # '''Voeg een bericht toe voor het Sysadmin Team, waarin u vraagt ​​om de pakketten te pushen'''. Pushen betekent het verplaatsen van de pakketten van het ene medium naar het andere. Voor QA betekent dit dat de sysadmins worden gevraagd om de SRPM te pushen van Backports Testing-media naar de bijbehorende Backports-media. Alle pakketten die in de SRPM zitten worden gepusht. De backport zal dan beschikbaar zijn voor alle Mageia-gebruikers als een gevalideerde backport.<br/><br/>Een voorbeeld van het type opmerking dat u kunt achterlaten:<br/><br/>''------------------------------------------------------------------------------------------<br/>Update validated. Line 188: Line 188:     * Mageia's volledige [[Herzieningen-beleid-nl|Mageia herzieningen-beleid]]. * Mageia's volledige [[Herzieningen-beleid-nl|Mageia herzieningen-beleid]]. −* De [[QA Tips and Trucs-nl|QA Tips en Trucs]] pagina zou u wat inspiratie moeten geven bij het uitvoeren van tests.+* De [[QA Tips en Trucs-nl|QA Tips en Trucs]] pagina zou u wat inspiratie moeten geven bij het uitvoeren van tests.  * [https://ml.mageia.org/wwsympa-wrapper.fcgi/info/qa-discuss QA-Discuss] mailinglijst: qa-discuss@ml.mageia.org * [https://ml.mageia.org/wwsympa-wrapper.fcgi/info/qa-discuss QA-Discuss] mailinglijst: qa-discuss@ml.mageia.org  * [https://ml.mageia.org/wwsympa-wrapper.fcgi/info/qa-bugs QA-Bugs] mailinglijst: qa-bugs@ml.mageia.org * [https://ml.mageia.org/wwsympa-wrapper.fcgi/info/qa-bugs QA-Bugs] mailinglijst: qa-bugs@ml.mageia.org Hugomarc

Created page with "Category:Contributors Category:QA Category:QA_procedures Category:Nederlands Category:Documentatie-nl {{draft}} == Wat is een backport? == Ons beleid is..."

New page

[[Category:Contributors]]
[[Category:QA]]
[[Category:QA_procedures]]
[[Category:Nederlands]]
[[Category:Documentatie-nl]]


{{draft}}
== Wat is een backport? ==
Ons beleid is om niet te updaten naar nieuwere versies van pakketten in stabiele Mageia-releases waar mogelijk, maar om patches toe te passen voor bugs en beveiligingskwetsbaarheden. Dit helpt om de stabiliteit van de distributie te vergroten. U zou bijvoorbeeld geen problemen met incompatibiliteit moeten ondervinden bij het updaten van een pakket. Een nieuwe versie voegt wellicht ondersteuning toe of verwijdert ondersteuning voor verschillende dingen, wat rampzalig kan zijn als u afhankelijk was van die ondersteuning voor iets belangrijks.

Een backport is een nieuwe versie van een pakket dat beschikbaar is in Cauldron, de ontwikkelingstak van Mageia, en beschikbaar wordt gesteld in onze stabiele releases in speciale backport-media. Deze media zijn standaard niet ingeschakeld en zijn niet bedoeld om te worden gebruikt als reguliere update-media.

Bijvoorbeeld:

Als er een pakket is met de naam xmoto: er kan xmoto-versie 3.2 beschikbaar zijn in de normale release-media of update-media. De functionaliteit van xmoto 3.2 zal niet zijn gewijzigd tussen het moment dat deze specifieke Mageia-versie werd uitgebracht en het huidige moment.

Cauldron heeft vaak de nieuwste versies, het is de plek waar de volgende Mageia-editie wordt gebouwd, maar het is niet stabiel en kan/zal kapotgaan. Dat is te verwachten.

Het kan zijn dat xmoto-versie 4 nu beschikbaar is in Cauldron, dus de beheerder van xmoto heeft besloten om het ook beschikbaar te maken in de stabiele Mageia-releases, omdat het een aantal mooie functies toevoegt die momenteel niet beschikbaar zijn. Hij kan dit doen door een backport van xmoto 4 in de stabiele releases te leveren met behulp van de backport-media.

[[QA Team Portal-nl|Terug naar de QA Team Portaal]]
<br/><br/><br/><br/>

== Hoe vind u backports die wachten op validatie ==
Om problemen te voorkomen, worden backports eerst gepusht naar een testing repository, wachtend op de validatie van het [[QA Team]].

U kunt backports die wachten op validatie vinden op [http://mageia.madb.org/tools/updates dezelfde pagina als de bugfix- en beveiligingsupdatekandidaten], of direct in [https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Backport%20waiting%20for%20QA%20test&sharer_id=22 Mageia's Bugzilla]. Er is een ''saved search'' op Bugzilla genaamd ''Backport waiting for QA test'' die u kunt vinden in uw voorkeuren. Als u het vakje rechts van de opgeslagen zoekopdracht aanvinkt, wordt er een link weergegeven in de voettekst van Bugzilla-pagina's.

De werkelijke pakketten staan ​​in de Backports Testing media, zoals hieronder:

<pre>
$PROTOCOL://$MIRROR/path/to/Mageia/distrib/$ARCH/media/$MEDIA/backports_testing

Bijvoorbeeld:
http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/core/backports_testing
</pre>

Dit voorbeeld komt overeen met "Core Backports Testing" in de mediamanager.
<br/><br/><br/><br/>

== Hoe valideert u een backport ==

Het proces voor het valideren van een backport is vergelijkbaar met dat voor [[QA proces voor het valideren van herzieningen (updates)-nl|het valideren van updates]], maar het testen is niet zo gedetailleerd. Als u de backport hebt verpakt, kunt u ook certificeren dat u deze op één architectuur hebt getest en dat telt mee voor de validatie. De persoon die het pakket aanvraagt ​​om te worden gebackporteerd, moet zoveel mogelijk bij het testen worden betrokken.

=== Controlelijst beleid ===

Voordat we beginnen met het testen van de backport, moeten we controleren of deze het [[Backports policy|Mageia backports beleid]] volgt.

Dingen waar u op moet letten:

[[File:backport.png|200px|thumb|right|De juiste Bugzilla-instellingen voor een gebackporteerd pakket dat is toegewezen aan QA.]]
* Backports worden alleen geaccepteerd voor leaf-pakketten of leaf-"groepen". Dit betekent pakketten die niet vereist zijn voor andere bestaande pakketten. Stelt u zich dit voor als een boom, de bladeren (leaves) zijn de buitenste delen die verwijderd kunnen worden zonder de twijgen of takken te beïnvloeden.<br/><br/>
* Op Bugzilla moeten backports worden ingesteld als ''Backport'' in het veld ''Component'' en ''lage'' prioriteit, en ze moeten door QA als de laagste prioriteit worden behandeld.<br/><br/>
* Er moet een gezond verstandadvies (advisory) worden verstrekt dat vergelijkbaar is met updates; de advisory moet RPM's en SRPM's vermelden, zodat we kunnen controleren of ze allemaal correct worden geïnstalleerd wanneer ze worden geselecteerd.<br/><br/>
* Als een pakket wordt ge-backport (teruggezet) voor Mageia 1, moet dezelfde of een nieuwere versie in Mageia 2 staan, hetzij Release, Updates of Backports<br/><br/>
* Als het teruggezette pakket afhankelijk is van een ander pakket om te werken, moet het ofwel werken met zowel de versie die beschikbaar is in Release/Updates als de versie in backports; of het pakket moet strikt versiegebonden vereisten hebben - dus het selecteren van het hoofdpakket zou alles wat nodig is inbrengen in de juiste versies.<br/><br/>
* Backports die nieuwe pakketten zijn, mogen geen andere pakketten van Release of Updates onbruikbaar maken<br/><br/>
* De packager '''kan''' certificeren dat hij een backport heeft getest op een specifieke Release en Architectuur; dit zal tellen als één voordeel richting validatie, mits hij uitlegt wat hij heeft getest. Dit betekent echter niet dat hij de tests kan voltooien en zijn eigen backports kan valideren zonder QA.<br/><br/>
* De persoon die oorspronkelijk heeft verzocht om het pakket voor hem te backporten, moet zoveel mogelijk bij de tests worden betrokken. We hopen dat het nieuwe bijdragers zal aanmoedigen!
<br/><br/><br/>

==

= Ontdek welke architectuur en Mageia-release u gebruikt ===
Om uw QA-werk correct te categoriseren, is het noodzakelijk om te weten welke architectuur en Mageia-release u gebruikt. Om dit te achterhalen, typt u
<pre>$ cat /etc/release </pre>
in een terminal in of opent u het bestand /etc/release in een willekeurige teksteditor. Vergelijk vervolgens de uitvoer met de volgende tabel:

{| class="wikitable"
|-
! Inhoud van /etc/release !! Architectuur !! Release (=Versie) !! Whiteboard-trefwoord
|-
| Mageia release 1 (Officieel) voor i586 || i586 || 1 || MGA1-32-OK
|-
| Mageia release 1 (Officieel) voor x86_64 || x86_64 || 1 || MGA1-64-OK
|-
| Mageia release 2 (Officieel) voor i586 || i586 || 2 || MGA2-32-OK
|-
| Mageia release 2 (Officieel) voor x86_64 || x86_64 || 2 || MGA2-64-OK
|}
<br/><br/><br/>

=== Laat het anderen weten ===

Om te voorkomen dat u hetzelfde werk doet als andere mensen van QA, en dubbel werk uitvoert, voegt u een bericht toe aan het update request (updateverzoek) op Bugzilla zodra u eraan begint. Gewoon iets simpels om anderen te laten weten dat u het test.

Een voorbeeld van het type bericht dat u kunt achterlaten:<br/><br/>''Testing i586, MGA2.<br/>Thanks.''

'''Note-nl''': "i586" (Architecture) en "MGA2" (Release) moeten overeenkomen met wat er op uw systeem aanwezig is.

We doen deze stap niet altijd omdat er meestal meer bugs zijn dan mensen, dus we botsen niet zo snel tegen elkaar aan, maar het kan worden gebruikt als het testen waarschijnlijk wat tijd kost, of als het iets populairs en makkelijks is om te testen.

Bij sommige complexe pakketten kan het nuttig zijn om meerdere mensen tegelijk te laten testen. Het kan nog steeds handig zijn om mensen te laten weten dat u (ook) de update test.
<br/><br/><br/><br/>

=== Test ===

# '''Installeer de juiste distributie met alle officieel uitgebrachte updates'''. Controleer het “Product”, “Version” en “Platform” in de header van het bugrapport, om uit te vinden wat het zou moeten zijn, bijvoorbeeld Mageia 1 x86_64. Merk ook op dat sinds de release van Mageia 2, sommige bugs backports kunnen bevatten voor beide releases, dus controleer ook het advies van de packager.<br/><br/>
# '''Schakel de relevante Backports Testing repository in uw bronnen in'''. Zie de pagina [[Enabling_the_Testing_media|schakel Testing Media in]] voor instructies over hoe u dit doet.<br/><br/>
# '''Installeer het backported pakket'''. Installeer niet alles van de Testing media, alleen de pakketten die u gaat testen. Zorg ervoor dat alle gerelateerde pakketten worden geselecteerd, inclusief alle vereiste libs. Er zou een lijst met alle RPM's in het bugrapport moeten staan.<br/><br/>
# '''Schakel de Testing repository opnieuw uit'''<br/><br/>
# '''Zorg ervoor dat u de backport nu hebt geïnstalleerd'''. Kijk [[How_to_find_a_source_RPM#Search_among_installed_packages_by_name|hier]] voor instructies.<br/><br/>
# '''Voer een paar snelle controles uit om na te gaan of de backport lijkt te werken'''. Het testen van backports hoeft niet zo grondig te zijn als het testen van updates. Het is voldoende om te controleren of het pakket netjes wordt geïnstalleerd met alle vereiste afhankelijkheden en of het goed lijkt te werken.
# '''Als er een nieuw pakket wordt geïntroduceerd''', controleer dan of het niet vraagt om een ​​ander pakket te verwijderen bij de installatie.
# '''Als de backport voor Mageia 1 is, zorg er dan voor dat er een hogere versie of dezelfde versie in Mageia 2 Release, Updates of Backports staat, zodat er een geldig upgradepad is.
# '''Doe wat snelle tests om te controleren of de update niets anders kapotmaakt'''. Omdat backports alleen leaf-pakketten moeten zijn die niets anders beïnvloeden of leaf-groepen van pakketten, mag het pakket geen andere dingen beïnvloeden.<br/><br/>
# '''Als uw tests een probleem hebben gevonden''', geef dan uw bevindingen door, door een opmerking over de bug achter te laten. De packager kan u om meer informatie vragen of verdere tests nodig hebben om het probleem op te sporen, dus wees voorbereid om dat verzoek op te volgen. Geef de release en architectuur op waarmee u testte.<br/>Bijvoorbeeld..<br/><br/>''Testing Mageia 2 i586.<br/>I have found a problem...etc.''<br/><br/>'''Note-nl''': "Mageia 2" (Release) en "i586" (Architecture) moeten weergeven wat er op uw systeem aanwezig is.<br/><br/>
# '''Als alles in orde is''', laat dan een opmerking achter om te zeggen dat u het testen hebt voltooid en voeg een trefwoord toe aan het Whiteboard. De Whiteboard-trefwoorden helpen ons bij te houden wanneer een bug klaar is om gevalideerd te worden.<br/>Bijvoorbeeld..<br/><br/>Commentaar: ''Testing complete Mageia 2 i586 for the SRPM chocolate-doom-1.7.0-1.mga2.src.rpm''<br/>Whiteboard: ''mga2-32-OK''<br/><br/>'''Note-nl''': "Mageia 2" (Release), "i586" (Architecture) en "mga2-32-OK" (Whiteboard-trefwoord) moeten weergeven wat er op uw systeem aanwezig is. Het trefwoord dat u moet gebruiken als u op een x86_64 Mageia 2-systeem test, zou "mga2-64-OK" zijn.<br/><br/>
# '''Als de bug klaar is om te valideren''', valideer hem dan. Een bug is pas klaar om te valideren als deze succesvol is getest op '''beide architecturen''' op '''alle releases''' waar hij werkzaam is. ​​Omdat sommige bugs backports bevatten voor meer dan één Mageia-release, moet '''elk''' worden voltooid '''voor zowel i586 als x86_64''' voordat de oplossing kan worden gevalideerd.
<br/><br/>

{{note-nl|* Vergeet niet om de i586-media in te schakelen op x86_64-systemen
* Mogelijk moet u de media ook updaten met <code>urpmi.update "media name"</code>. Bijvoorbeeld <code>urpmi.update "Core Backports Testing"</code>
* Stel nooit "Release" media in als update media wanneer u edit-urpm-sources.pl gebruikt, alleen "Updates" media.
* Vergeet niet om de Testing media uit te schakelen nadat u de pakketten hebt geïnstalleerd die u test.}}
<br/><br/><br/>

=== Valideren ===

# '''Schrijf een validatiebericht''' om mensen te laten weten dat de update correct is getest op beide architecturen en, indien nodig, alle releases.<br/><br/>
# '''Voeg een lijst toe van de geteste/goedgekeurde Source RPM's''' (SRPM's). Voor meer informatie over het vinden van de SRPM voor een pakket, zie de pagina [[How_to_find_a_source_RPM|Hoe vind ik een Sourde RPM]].<br/><br/>
# '''Voeg het advies (Advisory) toe, herschrijf deze indien nodig'''. De Advisory is een beschrijving die aan gebruikers wordt getoond als reden voor de backport, dus hij moet duidelijk zijn. Vraag de packager om de Advisory te verstrekken als deze ontbreekt, of als u niet weet wat u moet schrijven. Als de Advisory al wel is gepost en de huidige SRPM-versies toont, kopieer die tekst dan in uw opmerkingen of link gewoon naar het relevante commentaar. Bugzilla begrijpt woorden als ''bug 6334'' en ''commentaar 3'' en zal ze automatisch omzetten in links. Bijv. ''Zie commentaar 3 voor advies en SRPM''.<br/><br/>
# '''Voeg een bericht toe voor het Sysadmin Team, waarin u vraagt ​​om de pakketten te pushen'''. Pushen betekent het verplaatsen van de pakketten van het ene medium naar het andere. Voor QA betekent dit dat de sysadmins worden gevraagd om de SRPM te pushen van Backports Testing-media naar de bijbehorende Backports-media. Alle pakketten die in de SRPM zitten worden gepusht. De backport zal dan beschikbaar zijn voor alle Mageia-gebruikers als een gevalideerde backport.<br/><br/>Een voorbeeld van het type opmerking dat u kunt achterlaten:<br/><br/>''------------------------------------------------------------------------------------------<br/>Update validated.
Thanks.

Advisory:
--------------
This provides the new xmoto package for Mageia 1. It
adds a useful new xmoto widget for french fries which is not present in
the Release version.

It also disables support for Ketchup.
--------------

SRPM: xmoto.src.rpm

Could sysadmin please push from core/backports_testing to core/backports.

Thank you!<br/>------------------------------------------------------------------------------------------''<br/><br/>Vervolgens, bovenaan de pagina:<br/><br/>
# '''Voeg sysadmin-bugs@ml.mageia.org toe aan de 'CC'-lijst''' zodat het SysAdmin Team weet dat de backport klaar is om te worden gepusht. Zonder deze stap weten ze niet dat QA voltooid is en wordt het pakket niet verplaatst naar Updates, dus vergeet dat niet!<br/><br/>
# '''Voeg het trefwoord ''validated_update'' toe''' in het tekstvak ''Trefwoorden''.<br/><br/>
# '''Klik op ''Save''''' (opslaan)
<br/><br/>
[[QA Team Portal-nl|Ga terug naar de QA Team portaal]]
<br/><br/>

== Wat te doen als... ==

=== ...de packager het backports-beleid niet volgt ===

Als de bug informatie mist zoals de Advisory, SRPM's of lijst met RPM's, laat dan een bericht achter waarin de packager wordt gevraagd het [[Backports policy|backports-beleid]] te volgen.

Bijvoorbeeld:

''Please follow the backports policy and provide an advisory with your request.

https://wiki.mageia.org/en/Backports_policy

Please reassign to QA when you have had a chance to look at this.
Thank you.''

Verander vervolgens de status naar ''TOEGEWEZEN'' en wijs de bug opnieuw toe aan de persoon die om QA heeft gevraagd om het te valideren.
<br/><br/><br/>

=== ...de updatekandidaat lost het probleem niet op of creëert een ander probleem ===

Reageer gewoon in het update-verzoek (update request) door alle informatie over de bug of regressie te geven en op welke release en architectuur u testte. Wees voorbereid om te vervolgen met verdere tests of informatie, indien gevraagd.

Als er na een week geen reactie is, wijs de bug dan opnieuw toe aan de packager en wijzig de status naar ''ASSIGNED'' (toegewezen). <br/><br/><br/>

=== ...als u hulp of begeleiding nodig hebt of ergens niet zeker van bent ===

Vraag het gewoon! De enige domme vraag is degene die we nooit stellen omdat we het een domme vraag vinden. U kunt het op IRC vragen in #mageia-qa op irc.freenode.net of op de qa-discuss mailinglijst. Als er niemand beschikbaar is in #mageia-qa, kunt u het altijd ook proberen in #mageia-dev.
<!--
Dit is uit commentaar gehaald omdat het op dit moment niet werkt, dus deze sectie voegt geen nuttige informatie toe aan de site. Haal de commentaar weg als de scripts beschikbaar zijn. Bedankt.
== Hoe een update te pushen ==

[[File:Warning_Icon.png]] FIXME: Wordt binnenkort toegevoegd omdat het script nog niet is afgerond. Blijf op de hoogte!
Dit is gereserveerd voor beveiligingsmensen en QA-mensen met goede rechten om de scripts uit te voeren. Deze scripts verplaatsen updates van '*_testing' naar 'updates'.
Het eerste script verplaatst 'core', 'nonfree', 'tainted''.
Het tweede script verplaatst 'backport'.-->
<br/><br/><br/>

== Meer informatie ==

Raadpleeg de [[QA Team Portal-nl]] voor meer informatie over het [[QA Team|Mageia QA Team]].

* Mageia's volledige [[Herzieningen-beleid-nl|Mageia herzieningen-beleid]].
* De [[QA Tips and Trucs-nl|QA Tips en Trucs]] pagina zou u wat inspiratie moeten geven bij het uitvoeren van tests.
* [https://ml.mageia.org/wwsympa-wrapper.fcgi/info/qa-discuss QA-Discuss] mailinglijst: qa-discuss@ml.mageia.org
* [https://ml.mageia.org/wwsympa-wrapper.fcgi/info/qa-bugs QA-Bugs] mailinglijst: qa-bugs@ml.mageia.org

* U kunt ook [http://mageia.madb.org/rpm/list/listtype/updates_testing Mageia App Db] gebruiken om in behandeling zijnde update-kandidaten te zien en verschillende nuttige vergelijkingen uit te voeren.

* [[Sophie-nl]] is een bot op IRC die veel nuttige informatie biedt over Mageia-pakketten.

Probeer ''':help''' in #mageia-qa of ''':more ''packagename''' te typen Hugomarc

‎Most recent idea from the Forums, not yet merged (if possible) with the above: Remove merged section

← Older revision Revision as of 17:05, 29 September 2024 (10 intermediate revisions by the same user not shown)Line 17: Line 17:  Like asylum seekers who come from a "safe country" and can do nothing but wait till they get kicked out. Or like students who are not allowed to continue their study, because they don't fit well into the educational system. <br> Like asylum seekers who come from a "safe country" and can do nothing but wait till they get kicked out. Or like students who are not allowed to continue their study, because they don't fit well into the educational system. <br>  Wouldn't some of them be perfectly capable of learning Linux and learning so much of it that they would then be able to find a job (and in case that matters: a job that can be done remotely, so that they can return to their home country), earn a living and have a future? Isn't there is a better place to start than with Mageia and in Mageia. Wouldn't some of them be perfectly capable of learning Linux and learning so much of it that they would then be able to find a job (and in case that matters: a job that can be done remotely, so that they can return to their home country), earn a living and have a future? Isn't there is a better place to start than with Mageia and in Mageia.  +  +==Statistics needed regarding younger newgen developers==  +to remain in the linux world, I guess many of them are developing on other linux forks, e.g. android os or android apps, but here we need more statistics.     =How to reach potential contributors= =How to reach potential contributors=  +  +==What to tell potential contributors==  +Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.  +  +  * Demonstrate that contributing has tangible benefit to the community.  +  * Share details of what, specifically, help is needed with.  +  * Provide a clear path for getting involved.  +  +==Previously used methods that may need to be revived or enhanced==  +* Mageia blog posts  +* Forum posts  +* Mailing list messages  +* Presence at events  +** With a stand  +** With flyers at the stand  +** With a presentation (talk)  +* Twitter (X)?  +* Youtube  +* Facebook  +* TikTok ??  +  +==Proposed new methods==  +* Write an article and get it published in a magazine or on a website that many potential contributors read, about what contributing to Mageia can give you like:  +** experience in a project where people from many countries and cultures work.  +** experience in [[Contributing|one or more of many different fields]]  +** being able to contribute incognito. There is no need to show your passport (except probably for the few who become a board member), but you can contribute with any available user name and any desired "real name" or even without a "real name".  +** being credited for your contributions, regardless of your background, regardless of the current political situation, regardless of your gender, regardless of your skin color, regardless of your age, regardless of how much money you have, regardless of your religion.  +* Create a flyer that is meant to attract new contributors. Then flyer near a tech university, try to get in touch with tech and IT students  +* Similar for universities that offer translation studies, but then a dedicated flyer for future interpreters     =How to revive sleeping contributors= =How to revive sleeping contributors= Line 24: Line 56:  =Proposed changes to Mageia, to attract more contributors= =Proposed changes to Mageia, to attract more contributors=    −=='''Change to a state of the art, easy to use, powerfull and efficient build system==+==Create a list of most needed contributions (including priorities)==  +I contribute to more than one Linux distro but reviewing the [[contribute|contribution link]] provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.  +   +If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.  +   +We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one.  +==About packaging==  +==='''Change to a state of the art, easy to use, powerfull and efficient build system===  Like https://openbuildservice.org/.''' Like https://openbuildservice.org/.'''    Line 32: Line 71:     This (the above) would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager]. This (the above) would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].  +  +===Have small, self-organized packager groups===  +An idea for getting more packagers could be to let them self-organize in small groups of 2-3 people maximum, based on close, but complementary skills, to cooperate on building some package. One member of the group could help the other and viceversa.  +  +===Maintainership has growing costs===  +Beside personal life balance, developers or maintainers are actually not paid/rewarded so sometimes they could slowly fading or just slow down, as under certain circumstances the maintainership has growing costs (consider for instance following some upstream project having a release cycle of a month, if not weeks requiring continuosly updates), as might become almost a halftime or fulltime unpaid job.  +  +===The update to the new infra hardware should be pretty close.===  +  +Once it will be made it should bring a breath of fresh air to the distribution and let it be more "efficient" also to the packaging process. With the newer cpu power/storage there should be enough room/power to test new stuff, new developing tools (that are already used elsewhere in other distro) and new ideas/scheme beside to the classic tools, at least for the size and the ambition of the distro.     ==A contributor works for free for a project if he has confidence in its future.== ==A contributor works for free for a project if he has confidence in its future.== Line 61: Line 110:     =Most recent ideas from the Association members list, not yet merged (if possible) with the above= =Most recent ideas from the Association members list, not yet merged (if possible) with the above= −I write something just to the brainstorming Marja request. Don't take as written in stone.  −  −==The update to the new infra hardware should be pretty close.==  −Once it will be made it should bring a breath of fresh air to the distribution and let it be more "efficient" also to the packaging process. With the newer cpu power/storage there should be enough room/power to test new stuff, new developing tools (that are already used elsewhere in other distro) and new ideas/scheme beside to the classic tools, at least for the size and the ambition of the distro.  −  −==Maintainership has growing costs==  −Beside personal life balance, developers or maintainers are actually not paid/rewarded so sometimes they could slowly fading or just slow down, as under certain circumstances the maintainership has growing costs (consider for instance following some upstream project having a release cycle of a month, if not weeks requiring continuosly updates), as might become almost a halftime or fulltime unpaid job.     −==Statistics needed regarding younger newgen developers==+To increase the means of distribution, I would be in favor of opening up the association to its users and asking for a basic fee to finance these projects. I'm well aware that this would generate greater activity on the part of the treasurers, but it would force us to be more rigorous at the AGMs. These users could vote to elect a representative who would represent them on the board, but who would also be eligible for board positions (Treasurer, Secretary, etc.). −to remain in the linux world, I guess many of them are developing on other linux forks, e.g. android os or android apps, but here we need more statistics.  −   −==Have small, self-organized packager groups==  −An idea for getting more packagers could be to let them self-organize in small groups of 2-3 people maximum, based on close, but complementary skills, to cooperate on building some package. One member of the group could help the other and viceversa.  −=Most recent idea from the Forums, not yet merged (if possible) with the above=  −Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.  −   −  * Demonstrate that contributing has tangible benefit to the community.  −  * Share details of what, specifically, help is needed with.  −  * Provide a clear path for getting involved.  −   −   −I contribute to more than one Linux distro but reviewing [https://www.mageia.org/contribute/ the contribution link] provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.  −   −If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.     −We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one.+Could MLO, which is independent of Mageia but recognized by Mageia as a French-speaking forum, be represented on the Council? Is there always a leader present on the council to represent the mageia forums? Marja

Created page with "Category:QA Category:Doc Category:Nederlands Category:Documentatie-nl = Inleiding = Bij het testen van een update is de aanbevolen procedure om alleen de pak..."

New page

[[Category:QA]]
[[Category:Doc]]
[[Category:Nederlands]]
[[Category:Documentatie-nl]]

= Inleiding =

Bij het testen van een update is de aanbevolen procedure om alleen de pakketten te installeren die in de update-aanvraag (update request) staan. Dit is omdat dit de enige pakketten zijn die naar de {{file|updates}}-media worden gepusht wanneer de update is gevalideerd.

Als een tester de {{file|updates_testing}}-media inschakelt en handmatig de pakketten selecteert die moeten worden bijgewerkt, is er een kans dat andere pakketten die aanwezig zijn in {{file|updates_testing}} automatisch worden geïnstalleerd (vanwege pakketafhankelijkheden). Meestal veroorzaakt dit geen problemen, maar als de update daadwerkelijk een aantal van die extra pakketten vereist, zullen gebruikers problemen ondervinden zodra de update wordt gepusht, omdat die extra pakketten niet noodzakelijkerwijs beschikbaar zullen zijn in de {{file|updates}}-media.

Om dergelijke problemen te helpen voorkomen, is het gereedschap {{prog|QA Repo}} gemaakt. Dit gereedschap pakt een lijst met pakketten die door de tester zijn geleverd en maakt een lokale repository (pakketdepot) op de machine van de tester die alleen deze pakketten bevat. Vervolgens schakelt het QA Repo-gereedschap die repository in als een update-medium, zodat wanneer de tester de software-update-GUI (of {{cmd|urpmi –auto-select}}) uitvoert, die pakketten beschikbaar zijn als updates. Mits de tester nooit de media {{file|updates_testing}} inschakelt, is er geen gevaar dat andere pakketten in {{file|updates_testing}} worden geïnstalleerd.

Om problemen volledig te voorkomen, moeten de bijgewerkte pakketten opnieuw worden gedowngraded, voordat er wordt doorgegaan met het testen van een andere update-aanvraag. Momenteel moet dit nog steeds handmatig worden gedaan, maar het gereedschap {{prog|QA Repo}} kan u een opdracht voorstellen om dit te bereiken. Als u test in een virtuele machine, kunt u in plaats daarvan klonen of snapshots gebruiken om de wijzigingen terug te draaien.

= Installatie =

Het gereedschap {{prog|QA Repo}} kan worden geïnstalleerd in het systeem van de tester door het {{prog|qarepo}}-pakket te installeren. Let op: als u test in een virtuele machine, moet het pakket worden geïnstalleerd in het gastsysteem.

Meestal draait het gereedschap {{prog|QA Repo}} zonder speciale privileges, maar om de lokale repository in of uit te schakelen als updatemedium, zijn root-privileges vereist. QA Repo vraagt ​​alleen om deze privileges wanneer deze nodig zijn, en gebruikt hierbij polkit om de authenticatie uit te voeren (dit is de authenticatiedialoog die u ziet wanneer u andere programma's uitvoert die root-privileges vereisen, zoals het Mageia Control Center MCC).

Omdat de polkit-authenticatie al na een paar minuten verloopt, kunt u ervoor kiezen uzelf toe te voegen aan de {{cmd|qarepo}}-groep (via de gebruikersbeheertool in de MCC of de opdracht {{cmd|usermod}}). Dit zorgt ervoor dat polkit automatisch het gereedschap {{prog|QA Repo}} autoriseert om de acties uit te voeren die nodig zijn, zonder dat u een wachtwoord hoeft in te voeren, mits de tool door u wordt uitgevoerd als een actieve lokale gebruiker.

{{note-nl|Voor Mageia 6 is het {{prog|qarepo}} pakket beschikbaar in {{file|core/backports}}. Voor Mageia 7 en hoger is het beschikbaar in {{file|core/release}}.}}

= Instructies voor het gebruik =

Het gereedschap {{prog|QA Repo}} kan worden gestart door deze te selecteren in de {{menu|Tools}} sectie van het menu desktop applicaties, of door {{cmd|qarepo}} in te voeren op de opdrachtregel. Als u het commando uitvoert vanaf de opdrachtregel, ziet u de uitvoer van de opdrachten die {{prog|QA Repo}} uitvoert om de lokale repository te maken, wat handig kan zijn om fouten te diagnosticeren als het gereedschap niet doet wat u verwacht.

Zodra u bent begonnen, krijgt u de volgende grafische gebruikersschil (Graphical User Interface, GUI) te zien:

[[File:qarepo.png]]

== Een mirror selecteren ==

Op de eerste rij van de GUI staat een tekstvak waarmee u de URL van de mirror kunt invoeren die u wilt gebruiken om pakketten te downloaden. Dit kan een {{cmd|http://}}, {{cmd|ftp://}} of {{cmd|rsync://}} URL zijn, of een eenvoudig bestandspad (d.w.z. zonder het voorvoegsel {{cmd|file://}}) naar een mirror op uw lokale bestandssysteem. In alle gevallen moet dit verwijzen naar het hoogste niveau van de distributieboom (de directory met de subdirectory {{file|distrib}}).

== De bronmedia selecteren ==

Op de tweede rij van de GUI staat een tekstvak waarmee u het Mageia-releasenummer kunt invoeren dat u wilt testen en vakjes kunt aanvinken om te selecteren welke mediatypen zijn ingeschakeld (de {{file|core}}-media zijn altijd ingeschakeld). Op de derde rij staat een uitrol-menu waarmee u kunt selecteren welke architectuur u test ({{file|i586}} of {{file|x86_64}}).

Het gereedschap {{prog|QA Repo}} downloadt alleen pakketten uit de secties {{file|updates_testing}} van de geselecteerde media.

== De locatie van de lokale repository selecteren ==

Op de derde rij van de GUI staat een tekstvak waarmee u de locatie van de directory kunt opgeven, die wordt gebruikt om de lokale repository op te slaan die is gemaakt door het gereedschap {{prog|QA Repo}}. Dit moet een absoluut pad zijn op uw lokale bestandssysteem. De directory wordt gemaakt als deze nog niet bestaat. De lokale repository wordt gemaakt als een subdirectory van deze directory, vernoemd naar de geselecteerde architectuur.

== De te testen pakketten selecteren ==

Op de vierde rij van de GUI is er een tekstinvoervak ​​waarmee u kunt selecteren welke pakketten moeten worden gedownload en opgeslagen in de lokale repository. Het wordt aanbevolen om de lijst met RPM-namen uit de update-aanvraag (update request) in Bugzilla te kopiëren en te plakken. De packager (verpakker) die de update heeft aangevraagd, zou een complete lijst voor elke architectuur hebben moeten verstrekt, zoals vermeld in het [[Herzieningen-beleid-nl|Mageia Herzieningen-beleid]]. De vermeldingen moeten ten minste de pakketnaam (package name) en het volledige versienummer bevatten; de architectuur en de extensie {{cmd|.rpm}} worden automatisch gevonden als ze waren weggelaten.

Als u test binnen een VirtualBox-gast, is het handig om deze in te stellen op het gebruik van een bidirectioneel klembord. Hiermee kunt u de bug in de browser van de host oproepen, de pakketlijst uit de bug kopiëren en deze in de QA-repository van de gast plakken.

== Synchroniseren en inschakelen van de lokale repository ==

Wanneer u wijzigingen aanbrengt in de bovenstaande selecties, verandert de knop {{cmd|Enable}} (inschakelen) in de GUI in een knop {{cmd|Update}} (bijwerken), en toont de statusregel onder het pakketselectievak {{cmd|Needs Update}} (bijwerken nodig). Dit geeft aan dat de lokale repository momenteel niet de pakketten bevat die u hebt geselecteerd. Klik op de knop {{cmd|Update}} om te beginnen met het downloaden van de gevraagde pakketten van de geselecteerde mirror (spiegelserver). Als dit lukt, verandert de knop {{cmd|Update}} weer in een (grijze) knop {{cmd|Enable}}; de statusregel luidt nu {{cmd|Enabled}}. Uw lokale repository is nu ingeschakeld en u kunt beginnen met het installeren van de updates en het testen.

Als u de software media manager (of {{cmd|urpmq –list-media}}) uitvoert, ziet u uw lokale repository verschijnen als {{cmd|QA Testing (32-bit)}} of {{cmd|QA Testing (64-bit)}}, afhankelijk van de architectuur die u hebt geselecteerd. Er zijn geen submedia in de lokale repository – alle geselecteerde pakketten worden in één medium opgeslagen, ongeacht van welke media ze zijn gedownload.

Als de synchronisatie mislukt, wordt een pop-up dialoog weergegeven met de reden voor de mislukking en de statusregel toont {{cmd|Update failed}}. Probeer het probleem te verhelpen (bijvoorbeeld een verkeerd getypte pakketnaam) en klik op de knop {{cmd|Update}} om het opnieuw te proberen.

De knop {{cmd|Clear}} biedt een snelle manier om het pakketselectievak te wissen voordat u een nieuwe lijst met pakketten plakt. Let op dat de knop alleen het tekstvak leegmaakt – de lokale repository blijft ongewijzigd totdat u op de knop {{cmd|Update}} klikt.

Wanneer u op de knop {{cmd|Update}} klikt, worden alle pakketten die momenteel niet in het pakketselectievakje staan, uit de lokale repository verwijderd.

== De lokale repository uitschakelen ==

Zodra de lokale repository (pakketdepot) is ingeschakeld, is de knop {{cmd|Disable}} niet langer grijs. Als u op de knop {{cmd|Disable}} klikt, wordt uw lokale repository uitgeschakeld en verwijderd uit de lijst met bekende softwaremedia, en wordt de statusregel onder het pakketselectievakje {{cmd|Disabled}} weergegeven. De lokale repository blijft echter intact en kan opnieuw worden ingeschakeld door op de knop {{cmd|Enable}} te klikken.

== Pakketten downgraden na het testen ==

Zodra u klaar bent met het testen van een bepaalde update, wilt u de wijzigingen die u in uw testsysteem hebt aangebracht terugdraaien, zodat ze geen invloed hebben op latere tests. Als u op de knop {{cmd|Downgrade}} klikt, verschijnt er een pop-up dialoog met een opdracht die u kunt uitvoeren om automatisch alle pakketten te downgraden die momenteel in het pakketselectievak staan ​​en die op uw systeem zijn geïnstalleerd. Dit schakelt ook automatisch uw lokale repository uit als u dat nog niet hebt gedaan.

De downgrade vervangt de vermelde pakketten met de nieuwste versies die beschikbaar zijn in uw momenteel ingeschakelde urpmi-media. Controleer de lijst met pakketten waarvan {{cmd|urpmi}} aankondigt dat het op het punt staat ze te vervangen, gewoon om er zeker van te zijn dat urpmi niet iets doet wat het niet zou moeten doen.

== Dual architecture testing ==

Soms wilt u wellicht tegelijkertijd zowel 32-bits als 64-bits pakketten testen. Selecteer hiervoor eerst de {{cmd|i586}}-architectuur en maak en activeer een lokale repository voor de 32-bits pakketten. Selecteer vervolgens de {{cmd|x86_64}}-architectuur en maak en activeer een lokale repository voor de 64-bits pakketten. Als u de software media manager (of {{cmd|urpmq –list-media}}) uitvoert, ziet u zowel {{cmd|QA Testing (32-bit)}} als {{cmd|QA Testing (64-bit)}} in de lijst.

U kunt vrij schakelen tussen architecturen in het gereedschap {{prog|QA Repo}}. Deze geeft altijd de status van de repository weer voor de momenteel geselecteerde architectuur.

Vergeet niet om de repository voor beide architecturen uit te schakelen wanneer u klaar bent met testen.

== Extra controles ==

Als u {{file|updates_testing}} media hebt ingeschakeld wanneer u op de knoppen {{cmd|Enable}}, {{cmd|Update}} of {{cmd|Download}} klikt, verschijnt er een pop-up dialoog waarin u wordt gevraagd die media uit te schakelen voordat u het opnieuw probeert.

== Opgeslagen instellingen ==

Behalve de lijst met pakketten, worden alle hierboven beschreven selecties opgeslagen in het bestand {{file|~/.qareporc}} wanneer u het gereedschap {{prog|QA Repo}} afsluit; ze worden opnieuw geladen wanneer u QA Repo de volgende keer start. Bij het opnieuw opstarten, als uw lokale repository al bestaat (zelfs als deze is uitgeschakeld), wordt het pakketselectievak gevuld met de huidige inhoud van de repository.

= Niet-standaardgebruik =

Wanneer een grote update wordt voorbereid (zoals de grote Plasma-update voor Mageia 6), kan er een periode zijn waarin de lijst met te testen pakketten voortdurend verandert (omdat bugs worden gevonden en opgelost); intussen is er geen definitieve lijst in Bugzilla. Om testen in deze omstandigheden te vergemakkelijken, worden de volgende extra functies ondersteund:

1. RPM-namen kunnen eenvoudige jokers bevatten ({{cmd|?}} en {{cmd|*}}), waardoor groepen van pakketten met dezelfde naam kunnen worden geselecteerd met één invoer in het pakketselectievak.

2. De optie {{cmd|fuzzy version}} kan worden ingeschakeld, waardoor het versienummer in een RPM-naam automatisch wordt vervangen door een joker.

3. De optie {{cmd|add deps}} kan worden ingeschakeld, wat automatisch alle pakketafhankelijkheden toevoegt die kunnen worden gevonden in de {{file|updates_testing}} media.

Geen van deze functies mag worden gebruikt tijdens de laatste test en validatie van een updateverzoek, omdat ze het hoofddoel van de {{prog|QA Repo}} tool tenietdoen. Hugomarc

← Older revision Revision as of 18:54, 28 September 2024 (10 intermediate revisions by the same user not shown)Line 1: Line 1: −=Explanation=+{{introduction|     This page is meant to give an overview of all ideas that come up when brainstorming about how to increase the number of active contributors.<br> This page is meant to give an overview of all ideas that come up when brainstorming about how to increase the number of active contributors.<br> Line 7: Line 7:  Every idea may be added. When brainstorming, there are no wrong or stupid ideas. That said, ideas that don't comply with our [https://www.mageia.org/en/about/code-of-conduct/ code of conduct], will be removed. Every idea may be added. When brainstorming, there are no wrong or stupid ideas. That said, ideas that don't comply with our [https://www.mageia.org/en/about/code-of-conduct/ code of conduct], will be removed.    −The intention is to sort the ideas by general topic (like whom to reach out to, or proposed changes to Mageia, or how to reach potential contributors) on this page, to make later reviewing them easier. Topics can be added when needed.+The intention is to sort the ideas by general topic (like whom to reach out to, or proposed changes to Mageia, or how to reach potential contributors) on this page, to make later reviewing them easier. Topics can be added when needed.}}    −==Whom to reach out to==+=Whom to reach out to=    −==How to reach potential contributors==+==IT students who get plenty of education about Windows, but not about Linux==  +They still exist, universities and schools that ignore Linux. Just about everything one former IT student knew about Linux when he graduated, was what he had learnt in Mageia. Thanks to what he had learnt here, he became a Linux developer and has now been working in the tech industry for a decade.    −==How to revive sleeping contributors==+==Young people without a future==  +Like asylum seekers who come from a "safe country" and can do nothing but wait till they get kicked out. Or like students who are not allowed to continue their study, because they don't fit well into the educational system. <br>  +Wouldn't some of them be perfectly capable of learning Linux and learning so much of it that they would then be able to find a job (and in case that matters: a job that can be done remotely, so that they can return to their home country), earn a living and have a future? Isn't there is a better place to start than with Mageia and in Mageia.    −==Proposed changes to Mageia, to attract more contributors==+=How to reach potential contributors=    −'''Change to a state of the art, easy to use, powerfull and efficient build system like https://openbuildservice.org/.'''+=How to revive sleeping contributors=  +   +=Proposed changes to Mageia, to attract more contributors=  +   +=='''Change to a state of the art, easy to use, powerfull and efficient build system==  +Like https://openbuildservice.org/.'''     Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention.    −This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].+===Make it easier to become a packager===  +   +This (the above) would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].  +   +==A contributor works for free for a project if he has confidence in its future.==  +The foundations of mageia are sound. It's a community distribution with clear values. However, Our association governance doesn't work.  +===Improve our Association Governance:===  + *    => Membership of the association is based on merit and choice. However, this process is subjective and not based on clear rules.  + *    => There aren't enough ordinary meetings or general assemblies to make decisions. Exchanges between the Council and the Board are almost non-existent. At the very least, the Board should validate the major orientations of distribution.  + *    => What is our roadmap, what are our medium- and long-term objectives? If we don't know ourselves what we need to do and what we need to prioritize, how can we communicate calmly and attract new contributors?  +   +===Make it easier to become a contributor===  +In line with [https://wiki.mageia.org/en/Brainstorming_about_how_to_get_more_active_contributors#Make_it_easier_to_become_a_packager a previous item], but more general,is this idea:<br>  +A contributor will work on a project if he finds the tools he knows and if they are efficient.  +I think it might be useful to take stock of the onboarding process for new arrivals, and improve it. On the other hand, I'm not sure we take the time to step back and look at what's not working and improve it. I recognize that this requires teamwork.....  +   +===Make more decisions===  +We don't make enough decisions. At the moment, I think we still have IRC and matrix running in parallel. We should stop using IRC and invest more in Matrix, which makes sharing easier and is evolving to include video and sound.  +===Work on the servers===  +It is essential to improve speed and comfort for our developers. Perhaps we should reinforce the system team if it needs it, and call on new volunteers.  +===Use tools such as jira===  +They might enable a simple kanban to know what to do and what to prioritize. Each team could have its own space to manage its actions.  +===Invest in the sysadmin team===  +I don't know how our current solutions work, but investing in the system team to work on the architecture to automate/consolidate the build of packages, images and tests on recognized standards known to potential external contributors would be a plus.  +   +==Real Life and/or video meetings==  +We don't know enough about each other and we don't have enough opportunities to exchange ideas.  +How about getting together at least once in a while, face-to-face or remotely via video conferences, etc.? It's not easy to organize, but linux fairs are a good opportunity. It used to be done, but with covid we've lost those good habits. A small restaurant between contributors helps reinforce team spirit.  +==Evolve faster==  +In France, there is a very lively community that is developing around the promotion of video games under Linux. I think that some of these members are ready to help if we trust them and help them. Some of them are technically solid. They have an understanding of the graphic stacks under Linux and are attracted by the new features available (Wayland, Nvidia drivers, Mesa, Lutris, etc., kernel optimization settings). I am registered on their discord and can see how they manage to attract young people. Unfortunately, even if some use Mageia, many are on other distributions because Mageia does not evolve quickly enough. Some have proposed things to improve the look of the distribution, but they quickly stopped because they felt that we did not like breaking our habits and that ultimately we did not want to evolve.  +   +=Most recent ideas from the Association members list, not yet merged (if possible) with the above=  +I write something just to the brainstorming Marja request. Don't take as written in stone.  +   +==The update to the new infra hardware should be pretty close.==  +Once it will be made it should bring a breath of fresh air to the distribution and let it be more "efficient" also to the packaging process. With the newer cpu power/storage there should be enough room/power to test new stuff, new developing tools (that are already used elsewhere in other distro) and new ideas/scheme beside to the classic tools, at least for the size and the ambition of the distro.  +   +==Maintainership has growing costs==  +Beside personal life balance, developers or maintainers are actually not paid/rewarded so sometimes they could slowly fading or just slow down, as under certain circumstances the maintainership has growing costs (consider for instance following some upstream project having a release cycle of a month, if not weeks requiring continuosly updates), as might become almost a halftime or fulltime unpaid job.  +   +==Statistics needed regarding younger newgen developers==  +to remain in the linux world, I guess many of them are developing on other linux forks, e.g. android os or android apps, but here we need more statistics.  +   +==Have small, self-organized packager groups==  +An idea for getting more packagers could be to let them self-organize in small groups of 2-3 people maximum, based on close, but complementary skills, to cooperate on building some package. One member of the group could help the other and viceversa.  +=Most recent idea from the Forums, not yet merged (if possible) with the above=  +Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.  +   +  * Demonstrate that contributing has tangible benefit to the community.  +  * Share details of what, specifically, help is needed with.  +  * Provide a clear path for getting involved.  +   +   +I contribute to more than one Linux distro but reviewing [https://www.mageia.org/contribute/ the contribution link] provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.  +   +If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.  +   +We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one. Marja

‎Most recent ideas from the Association members list, not yet merged (if possible) with the above

← Older revision Revision as of 17:33, 28 September 2024 (7 intermediate revisions by the same user not shown)Line 10: Line 10:     ==Whom to reach out to== ==Whom to reach out to==  +  +===IT students who get plenty of education about Windows, but not about Linux===  +They still exist, universities and schools that ignore Linux. Just about everything one former IT student knew about Linux when he graduated, was what he had learnt in Mageia. Thanks to what he had learnt here, he became a Linux developer and has now been working in the tech industry for a decade.  +  +===Young people without a future===  +Like asylum seekers who come from a "safe country" and can do nothing but wait till they get kicked out. Or like students who are not allowed to continue their study, because they don't fit well into the educational system. <br>  +Wouldn't some of them be perfectly capable of learning Linux and learning so much of it that they would then be able to find a job (and in case that matters: a job that can be done remotely, so that they can return to their home country), earn a living and have a future? Isn't there is a better place to start than with Mageia and in Mageia.     ==How to reach potential contributors== ==How to reach potential contributors== Line 17: Line 24:  ==Proposed changes to Mageia, to attract more contributors== ==Proposed changes to Mageia, to attract more contributors==    −'''Change to a state of the art, easy to use, powerfull and efficient build system like https://openbuildservice.org/.'''+==='''Change to a state of the art, easy to use, powerfull and efficient build system===  +Like https://openbuildservice.org/.'''     Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention.    −This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].+====Make it easier to become a packager====  +   +This (the above) would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].  +   +===A contributor works for free for a project if he has confidence in its future.===  +The foundations of mageia are sound. It's a community distribution with clear values. However, Our association governance doesn't work.  +====Improve our Association Governance:====  + *    => Membership of the association is based on merit and choice. However, this process is subjective and not based on clear rules.  + *    => There aren't enough ordinary meetings or general assemblies to make decisions. Exchanges between the Council and the Board are almost non-existent. At the very least, the Board should validate the major orientations of distribution.  + *    => What is our roadmap, what are our medium- and long-term objectives? If we don't know ourselves what we need to do and what we need to prioritize, how can we communicate calmly and attract new contributors?  +   +====Make it easier to become a contributor====  +In line with [https://wiki.mageia.org/en/Brainstorming_about_how_to_get_more_active_contributors#Make_it_easier_to_become_a_packager a previous item], but more general,is this idea:<br>  +A contributor will work on a project if he finds the tools he knows and if they are efficient.  +I think it might be useful to take stock of the onboarding process for new arrivals, and improve it. On the other hand, I'm not sure we take the time to step back and look at what's not working and improve it. I recognize that this requires teamwork.....  +   +====Make more decisions====  +We don't make enough decisions. At the moment, I think we still have IRC and matrix running in parallel. We should stop using IRC and invest more in Matrix, which makes sharing easier and is evolving to include video and sound.  +====Work on the servers====  +It is essential to improve speed and comfort for our developers. Perhaps we should reinforce the system team if it needs it, and call on new volunteers.  +====Use tools such as jira====  +They might enable a simple kanban to know what to do and what to prioritize. Each team could have its own space to manage its actions.  +====Invest in the sysadmin team====  +I don't know how our current solutions work, but investing in the system team to work on the architecture to automate/consolidate the build of packages, images and tests on recognized standards known to potential external contributors would be a plus.  +   +===Real Life and/or video meetings===  +We don't know enough about each other and we don't have enough opportunities to exchange ideas.  +How about getting together at least once in a while, face-to-face or remotely via video conferences, etc.? It's not easy to organize, but linux fairs are a good opportunity. It used to be done, but with covid we've lost those good habits. A small restaurant between contributors helps reinforce team spirit.  +===Evolve faster===  +In France, there is a very lively community that is developing around the promotion of video games under Linux. I think that some of these members are ready to help if we trust them and help them. Some of them are technically solid. They have an understanding of the graphic stacks under Linux and are attracted by the new features available (Wayland, Nvidia drivers, Mesa, Lutris, etc., kernel optimization settings). I am registered on their discord and can see how they manage to attract young people. Unfortunately, even if some use Mageia, many are on other distributions because Mageia does not evolve quickly enough. Some have proposed things to improve the look of the distribution, but they quickly stopped because they felt that we did not like breaking our habits and that ultimately we did not want to evolve.  +   +==Most recent ideas from the Association members list, not yet merged (if possible) with the above==  +I write something just to the brainstorming Marja request. Don't take as written in stone.  +   +===The update to the new infra hardware should be pretty close.===  +Once it will be made it should bring a breath of fresh air to the distribution and let it be more "efficient" also to the packaging process. With the newer cpu power/storage there should be enough room/power to test new stuff, new developing tools (that are already used elsewhere in other distro) and new ideas/scheme beside to the classic tools, at least for the size and the ambition of the distro.  +   +===Maintainership has growing costs===  +Beside personal life balance, developers or maintainers are actually not paid/rewarded so sometimes they could slowly fading or just slow down, as under certain circumstances the maintainership has growing costs (consider for instance following some upstream project having a release cycle of a month, if not weeks requiring continuosly updates), as might become almost a halftime or fulltime unpaid job.  +   +===Statistics needed regarding younger newgen developers===  +to remain in the linux world, I guess many of them are developing on other linux forks, e.g. android os or android apps, but here we need more statistics.  +   +===Have small, self-orgaized packager groups===  +An idea for getting more packagers could be to let them self-organize in small groups of 2-3 people maximum, based on close, but complementary skills, to cooperate on building some package. One member of the group could help the other and viceversa.  +==Most recent idea from the Forums, not yet merged (if possible) with the above==  +Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.  +   +  * Demonstrate that contributing has tangible benefit to the community.  +  * Share details of what, specifically, help is needed with.  +  * Provide a clear path for getting involved.  +   +   +I contribute to more than one Linux distro but reviewing the contribution link above provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.  +   +If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.  +   +We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one. Marja

← Older revision Revision as of 11:33, 28 September 2024 Line 27: Line 27:  # The next step is to move an internal library from the '''libs''' folder to the '''bin''' folder. # The next step is to move an internal library from the '''libs''' folder to the '''bin''' folder.  ## <code>sudo mv /opt/resolve/libs/libBlackmagicRawAPI.so /opt/resolve/bin/</code> ## <code>sudo mv /opt/resolve/libs/libBlackmagicRawAPI.so /opt/resolve/bin/</code>  +  +=== Troubleshooting ===     I've experienced that DaVinci Resolve doesn't always start right after installation and that a reboot was necessary. Do not know why, but it does work if everything else fails. I've experienced that DaVinci Resolve doesn't always start right after installation and that a reboot was necessary. Do not know why, but it does work if everything else fails.    −== Converting mp4 to ProRes format ==+Sometimes nothing works and it may be time to start fresh. You can either delete or rename the DaVinci configuration directory.  +This can be found in '''${HOME}/.local/share/DaVinciResolve/'''  +   += Converting mp4 to ProRes format =     DaVinci Resolve does not support x264/x265 videos and you will have to convert these to the Apple ProRes format. The most commonly used format supported by ffmpeg is '''prores_ks'''. DaVinci Resolve does not support x264/x265 videos and you will have to convert these to the Apple ProRes format. The most commonly used format supported by ffmpeg is '''prores_ks'''. Line 42: Line 47:     for i in *.$1; do ffmpeg -i "$i" -c:v prores_ks -profile:v 3 -vendor apl0 -bits_per_mb 8000 -pix_fmt yuv422p10le -c:a pcm_s16le "Prores/${i%.*}.mov"; done    for i in *.$1; do ffmpeg -i "$i" -c:v prores_ks -profile:v 3 -vendor apl0 -bits_per_mb 8000 -pix_fmt yuv422p10le -c:a pcm_s16le "Prores/${i%.*}.mov"; done    −=== Usage of the script ===+== Usage of the script ==     I named my script '''2prores''' and placed in '''~/bin/'''. I named my script '''2prores''' and placed in '''~/bin/'''. Line 54: Line 59:  The '''prores''' files are quite a bit larger than their '''mp4''' counterparts, so make sure you have enough disk space to house them. The '''prores''' files are quite a bit larger than their '''mp4''' counterparts, so make sure you have enough disk space to house them.    −== No native x264/x265 export in DaVinci Resolve ==+= No native x264/x265 export in DaVinci Resolve =     DaVinci Resolve doesn't support exporting to x264/x265 on Linux and you will have to convert them after you have rendered your finished video. DaVinci Resolve doesn't support exporting to x264/x265 on Linux and you will have to convert them after you have rendered your finished video. Line 75: Line 80:     for i in *.$1; do ffmpeg -i "$i" -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 384k "out/${i%.*}.mp4"; done    for i in *.$1; do ffmpeg -i "$i" -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 384k "out/${i%.*}.mp4"; done    −=== Usage of the scripts ===+== Usage of the scripts ==  Place the 2 scripts in '''~/bin/''' and make them executable. Place the 2 scripts in '''~/bin/''' and make them executable.    Kekepower

added NL banner

← Older revision Revision as of 10:49, 28 September 2024 Line 2: Line 2:  [[Category:QA]] [[Category:QA]]    −{{Multi language banner-fr|[[QA Prozess zum Testen von Installationen-de|Deutsch]] ; [[QA_process_for_testing_installations|English]] ; [[Qualification pour les tests d'installations-fr|français]] ;}}+{{Multi language banner-fr|[[QA Prozess zum Testen von Installationen-de|Deutsch]] ; [[QA_process_for_testing_installations|English]] ; [[Qualification pour les tests d'installations-fr|français]] ; [[QA proces voor het testen van installaties-nl|Nederlands]] ;}}     == En quoi consiste une installation ? == == En quoi consiste une installation ? == Hugomarc

added NL banner

← Older revision Revision as of 10:48, 28 September 2024 Line 1: Line 1: −{{multi_language_banner|[[QA Prozess zum Testen von Installationen-de|Deutsch]] ; [[QA_process_for_testing_installations|English]] ; [[Qualification pour les tests d'installations-fr|français]] ;}}+{{multi_language_banner|[[QA Prozess zum Testen von Installationen-de|Deutsch]] ; [[QA_process_for_testing_installations|English]] ; [[Qualification pour les tests d'installations-fr|français]] ; [[QA proces voor het testen van installaties-nl|Nederlands]] ;}}     == What is an installation? == == What is an installation? == Hugomarc

added NL banner

← Older revision Revision as of 10:48, 28 September 2024 Line 1: Line 1:  [[Category:Mitwirken]] [[Category:Mitwirken]]  [[Category:QA]] [[Category:QA]] −{{multi_language_banner-de|[[QA Prozess zum Testen von Installationen-de|Deutsch]] ; [[QA_process_for_testing_installations|English]] ; [[Qualification pour les tests d'installations-fr|français]] ;}}+{{multi_language_banner-de|[[QA Prozess zum Testen von Installationen-de|Deutsch]] ; [[QA_process_for_testing_installations|English]] ; [[Qualification pour les tests d'installations-fr|français]] ; [[QA proces voor het testen van installaties-nl|Nederlands]] ;}}  {{mgaport-de|url=QA_Prozess_zum_Testen_von_Installationen}} {{mgaport-de|url=QA_Prozess_zum_Testen_von_Installationen}}    Hugomarc

typo Qa/QA

Show changes Hugomarc

‎Proposed changes to Mageia, to attract more contributors

← Older revision Revision as of 05:51, 28 September 2024 Line 21: Line 21:  Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention.    −This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [[https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager]].+This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager]. Sturmvogel

‎Proposed changes to Mageia, to attract more contributors

← Older revision Revision as of 05:51, 28 September 2024 (One intermediate revision by the same user not shown)Line 16: Line 16:     ==Proposed changes to Mageia, to attract more contributors== ==Proposed changes to Mageia, to attract more contributors==  +  +'''Change to a state of the art, easy to use, powerfull and efficient build system like https://openbuildservice.org/.'''  +  +Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention.  +  +This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager]. Sturmvogel

‎Explanation: enhance

← Older revision Revision as of 14:26, 27 September 2024 Line 1: Line 1:  =Explanation= =Explanation=    −This page is meant to give an overview of all ideas that come up when brainstorming about how to win more contributors.<br>+This page is meant to give an overview of all ideas that come up when brainstorming about how to increase the number of active contributors.<br>  The ideas are expected to be unfiltered, the filtering will be done later.<br> The ideas are expected to be unfiltered, the filtering will be done later.<br>  So it is, for instance, perfectly fine to add ideas that are contrary to already added ideas.<br> So it is, for instance, perfectly fine to add ideas that are contrary to already added ideas.<br> Marja

‎Explanation: enhance

← Older revision Revision as of 14:26, 27 September 2024 (One intermediate revision by the same user not shown)Line 1: Line 1:  =Explanation= =Explanation=    −This page is meant to give an overview of all ideas that come up when brainstorming about how to win more contributors.<br>+This page is meant to give an overview of all ideas that come up when brainstorming about how to increase the number of active contributors.<br>  The ideas are expected to be unfiltered, the filtering will be done later.<br> The ideas are expected to be unfiltered, the filtering will be done later.<br>  So it is, for instance, perfectly fine to add ideas that are contrary to already added ideas.<br> So it is, for instance, perfectly fine to add ideas that are contrary to already added ideas.<br> Line 12: Line 12:     ==How to reach potential contributors== ==How to reach potential contributors==  +  +==How to revive sleeping contributors==     ==Proposed changes to Mageia, to attract more contributors== ==Proposed changes to Mageia, to attract more contributors== Marja