Aller au contenu

Concept : Contribution & Gouvernance des Buckets

Navigation : Documentation > Contribution
Charte générale de contribution : Charte Complète de Contribution

Sommaire

  1. Principes de Contribution
  2. Segmentation des 4 Buckets Officiels
  3. Bucket core : Utilitaires fondamentaux
  4. Bucket gui : Applications de bureau
  5. Bucket community : Outils émergents et de niche
  6. Bucket commercial : Logiciels propriétaires et sous licence
  7. Le Pipeline CI/CD d'Intégration Automatisé
  8. Comment Proposer un Nouveau Paquet
  9. Liens et Références Associées

1. Principes de Contribution

L'écosystème Érable est conçu pour être à la fois ouvert à la communauté et rigoureusement automatisé. Afin d'éviter les goulots d'étranglement humains rencontrés par d'autres gestionnaires de paquets :

  • Audit automatisé par CI/CD : Des bots d'intégration inspectent chaque soumission de paquet.
  • Règles d'acceptation objectives : Des critères clairs (popularité, licence, tests d'exécution) déterminent dans quel bucket un logiciel est accueilli.
  • Sécurité supply-chain garantie : Aucune contribution ne peut contourner la vérification des sommes de contrôle SHA-256 et l'analyse de sécurité des scripts (Zero Egress).

2. Segmentation des 4 Buckets Officiels

Chaque logiciel est assigné à l'un des quatre buckets officiels selon des critères précis :

flowchart TD
    PKG["Nouveau Paquet Proposé"] --> Q_LIC{"Licence Propriétaire / EULA ?"}
    Q_LIC -->|Oui| COMM["Bucket commercial"]
    Q_LIC -->|Non (Open Source)| Q_GUI{"Interface Graphique (GUI) ?"}
    Q_GUI -->|Oui| GUI["Bucket gui"]
    Q_GUI -->|Non (CLI / TUI)| Q_POP{"FOSS >= 500 Stars & Multiplateforme ?"}
    Q_POP -->|Oui| CORE["Bucket main / core"]
    Q_POP -->|Non (Moins de 500 stars ou niche)| COMMU["Bucket community"]

2.1 Bucket main / core : Utilitaires fondamentaux

  • Vocation : Les outils en ligne de commande de référence (git, ripgrep, kubectl, neovim, bat, etc.).
  • Critères : Licence FOSS reconnue (OSI), $\ge 500$ étoiles GitHub/GitLab, support d'au moins 2 systèmes d'exploitation, tests automatisés obligatoires (check_version, check_help).
  • 👉 Consulter la charte détaillée du Bucket Core

2.2 Bucket gui : Applications de bureau

  • Vocation : Logiciels fenêtrés nécessitant des raccourcis dans le menu Démarrer ou le dossier /usr/share/applications.
  • Critères : Déclaration obligatoire de parts/shortcuts.toml, icônes et désinstallation propre sans résidus.
  • 👉 Consulter la charte détaillée du Bucket GUI

2.3 Bucket community : Outils émergents et de niche

  • Vocation : Projets open source récents (< 500 étoiles), outils développés par des contributeurs indépendants.
  • Critères : Audit rigoureux par le linter AST anti-exfiltration, pas d'appels réseau non supervisés.
  • 👉 Consulter la charte détaillée du Bucket Community

2.4 Bucket commercial : Logiciels propriétaires et sous licence

  • Vocation : Outils indispensables aux développeurs mais soumis à une licence commerciale ou EULA (ex: IDEs propriétaires, outils cloud spécifiques).
  • Critères : Téléchargement direct depuis les serveurs officiels de l'éditeur (aucun miroir tiers), obligation du drapeau --accept-license pour l'utilisateur.
  • 👉 Consulter la charte détaillée du Bucket Commercial

3. Le Pipeline CI/CD d'Intégration Automatisé

Le dépôt core héberge le bot d'automatisation CI/CD (scripts/ci/) qui s'exécute régulièrement :

  1. Découverte des requêtes : Lecture des issues formatées avec les étiquettes correspondantes.
  2. Contrôle syntaxique : Validation des fichiers TOML de parts/.
  3. Téléchargement et empreinte : Téléchargement dans un environnement éphémère sandboxé et calcul du hash SHA-256.
  4. Exécution des tests de fumée (Smoke tests) : Vérification de la commande --version et --help.
  5. Génération de la Merge Request : Création automatique de la proposition de fusion prête à être approuvée.

4. Comment Proposer un Nouveau Paquet

  1. Identifier le bon bucket selon l'arbre de décision ci-dessus.
  2. Créer les fichiers manifestes dans packages/<initiale>/<nom-paquet>/parts/ :
  3. package.toml
  4. targets.toml
  5. Tester localement l'installation avec votre moteur Érable : 
    erable install <nom-paquet>
  6. Ouvrir une Merge Request sur le dépôt du bucket cible sur GitLab.

5. Liens et Références Associées