Systèmes de développement distribués

Question

Je suis intéressé par un système qui permet le développement distribué avec une pièce d'authentification. Qu'est-ce que je veux dire par là? Ok, prenons SVN, SVN garde une trace des révisions et ne se soucie pas de qui soumet, tant que vous avez le droit de soumettre, vous pouvez soumettre, en fait, à n'importe quelle partie dans le référentiel. Où mon système entre-t-il en jeu? Etre capable de granuler le contrôle d'accès et donner un stackoverflow comme sentir à l'environnement.

Dans le système que je décris nous avons 4 utilisateurs Bob, Alice, Dan, Joe. Bob est un projet géré, Alice et Dan sont des programmeurs sous Bob et Joe est un programmeur aléatoire sur Internet qui veut aider. Idéalement, dans ce système, Bob peut apporter des modifications et ne nécessitera pas d'approbation. Alice et Dan peuvent s'engager dans leurs succursales ou dans une succursale, mais un engagement envers le coffre devrait être approuvé par Bob.
C'est là que Joe vient, veut aider, mais vous ne voulez pas lui donner les clés du royaume pour ainsi dire, donc dans mon système, vous devez créer un compte "utilisateur faible". Tous les engagements que Joe prend devront être approuvés par Dan, Alice ou les deux. Cependant, dans le système, Joe peut construire un "Karma" où, après tant de validations approuvées, il aurait seulement besoin de l'approbation de l'un des programmeurs, et finalement, aucune approbation ne serait nécessaire.

Est-ce que cela a du sens et savez-vous si un tel système existe? Ou suis-je juste fou de penser même qu'un tel système/environnement serait possible?

Answer 1

Une question qui doit toujours être posée est la suivante: Pourquoi votre solution est-elle meilleure que les solutions existantes? Par exemple, pourquoi ne pas utiliser un système réparti et demander à des utilisateurs aléatoires de faire appel à une personne qui peut ensuite les récupérer si nécessaire. Au fil du temps, si le développeur le prouve, donnez-lui simplement accès en tant qu'administrateur.

Je sais qu'il serait cool d'avoir tout cela automatisé, mais le code source d'engagement ne se produit pas si souvent qu'un administrateur ne peut pas gérer l'ajout de personnes à la main.

Answer 2

Vous pouvez définir des autorisations d'annuaire pour la subversion, ce qui réduit la grande majorité des problèmes auxquels vous faites référence avec Alice et Dan.

La façon dont la plupart des projets gèrent le cas de Dan est de lui permettre de soumettre des correctifs qui sont ensuite transférés dans un commit par un superviseur.

Answer 3

Tout système de contrôle de version distribuée décent, comme Git ou Mercurial, peut le faire. Ceux qui ont la permission de pousser peuvent pousser, d'autres doivent envoyer des demandes de retrait. La seule caractéristique manquante est la construction automatique de ce que vous appelez "Karma".

C'est ainsi que la plupart des projets open source s'exécutent.

Answer 4

Hm ... Souhaits intéressants ...

Voyons voir. Vous pouvez faire 3 branches:

• finale
• Développement
• Unsafe

Bob peut engager dans Final. Alice et Dan peuvent s'engager dans Development et Joe peut s'engager dans Unsafe.

L'approbation est en fait la fusion des changements d'une branche inférieure à une branche supérieure. Par exemple: Joe est approuvé lorsque son code est fusionné par Alice ou Dan dans la branche Development. De même, l'approbation pour Alice et Dan est la fusion de leur code, par Bob, dans la branche Final.

Pour Karma est un peu plus compliqué. Vous pouvez écrire un script qui vérifiera de temps en temps le nombre de fusions (approbations) pour un utilisateur. Lorsqu'un certain seuil est dépassé, l'utilisateur est promu (le script lui donne accès aux branches supérieures).