Aller au contenu

01. Règles d'Acceptation du Bucket main

Navigation : Documentation > Chartes de Contribution > Règles Bucket Main

Sommaire

  1. Critères d'Éligibilité Stricts
  2. Popularité et Légitimité Communautaire
  3. Licence Logicielle et Transparence
  4. Portabilité Multiplateforme
  5. Exigences Techniques dans les Manifestes
  6. Sanity Checks Obligatoires
  7. Zéro Dépendance Système Impérative
  8. Surveillance Automatisée
  9. Exemple de Manifeste Conforme

Le bucket main constitue le socle fondamental de erable. Il regroupe les outils en ligne de commande (CLI / TUI) essentiels, matures et reconnus de l'écosystème du développement.

1. Critères d'Éligibilité Stricts

Pour qu'un paquet soit accepté dans le bucket main, il doit impérativement satisfaire à l'ensemble des critères suivants :

1.1 Popularité et Légitimité Communautaire

  • Nombre d'étoiles minimum : Le dépôt source officiel (GitHub, GitLab, Codeberg) doit cumuler au minimum 500 étoiles (stars).
  • Activité du projet : Le projet doit être activement maintenu (au moins un commit ou une release au cours des 12 derniers mois).
  • Adoption éprouvée : L'outil doit répondre à un cas d'usage généraliste et être couramment utilisé dans la communauté des développeurs.
  • Prévention de la manipulation d'étoiles (Star Gaming) : L'intégration continue analyse de façon 100% automatisée la vélocité et les métriques du dépôt (ratio stars/forks/issues, historique continu d'au moins 6 mois). Si les seuils algorithmiques sont satisfaits, la publication est débloquée sans goulot d'étranglement humain.

1.2 Licence Logicielle et Transparence

  • 100% Open Source (FOSS) : La licence doit être explicitement reconnue par l'OSI (ex: MIT, Apache-2.0, BSD-3-Clause, GPLv3, MPL-2.0, Unlicense).
  • Les logiciels propriétaires, freewares sans code source ouvert ou licences commerciales sont strictement interdits dans core (ils doivent être soumis dans le bucket commercial).

1.3 Portabilité Multiplateforme

  • Le paquet doit proposer des cibles binaires fonctionnelles pour au moins 2 des 3 systèmes d'exploitation majeurs (Windows, Linux, macOS).
  • Sauf exception justifiée, les cibles x86_64 et aarch64 (ARM64) doivent être couvertes.

2. Exigences Techniques dans les Manifestes

2.1 Sanity Checks Obligatoires (parts/verification.toml)

Chaque paquet doit obligatoirement définir :

  1. check_version : Une commande exécutable renvoyant la version exacte du paquet et validée par une expression régulière stricte.
  2. check_help : Une commande --help renvoyant un code de sortie 0 et confirmant l'affichage des instructions d'utilisation.

2.2 Zéro Dépendance Système Impérative

  • Les binaires doivent être autant que possible compilés en statique (musl sous Linux, runtime C autonome ou déclaration explicite de vcredist-2022).
  • Les paquets ne doivent pas nécessiter d'élévation de privilèges administrateur (UAC / sudo).

2.3 Surveillance Automatisée (parts/autoupdate.toml)

  • Tout paquet soumis dans main doit obligatoirement inclure un bloc parts/autoupdate.toml configuré pour que le bot CI puisse mettre à jour automatiquement les futures versions sans intervention humaine.

3. Processus d'Audit et Validation 100% Automatisé

  • Zéro Approbation Humaine Requise : Si l'ensemble des critères d'éligibilité, des audits de sécurité et des tests d'intégrité sont satisfaits, la fusion et la publication dans le bucket sont 100% automatiques.
  • Passage des Tests CI Obligatoire : Tous les workflows d'intégrité (linter AST anti-exfiltration, conformité des schémas TOML, vérification cryptographique SHA-256 et provenance SLSA 3, tests d'exécution de check_version et check_help) doivent être au vert.