Nunit: Déprécier le package de framework Chocolatey existant

Cela me semble bien. Conformément à la philosophie chocolatée (et nuget), je pense qu'il devrait être divisé en plusieurs pacages, éventuellement avec des dépendances. S'il existe une bonne installation chocolatée pour le coureur de console plus le moteur, alors j'envisagerais de supprimer le package nuget équivalent.

Cela devrait être fait, mais comme une installation chocolatée envelopperait essentiellement nos autres installations, la mise en œuvre devrait attendre jusqu'à ce que nous déterminions quelles autres installations nous prenons en charge.

@CharliePoole , cela m'intéresse et j'ai quelques questions pour la mise en œuvre.

• À part un programme d'installation bin et Windows, quelles autres installations NUnit envisage-t-il ?
• Étant donné que les versions NUnit de manière sémantique, le groupe serait-il d'accord pour garder les versions du package Chocolatey synchronisées au lieu de publier plusieurs packages différents ?
• Ai-je raison de dire qu'un package Chocolatey de NUnit devrait inclure à la fois le moteur et le coureur de la console ?

Merci!

@DustinVenegas Gardez à l'esprit que ce référentiel est pour NUnit 3.0, qui est substantiellement réécrit à partir de NUnit 2.x. Nous pouvons même le traiter comme un nouveau produit à des fins chocolatées - ce n'est pas encore décidé.

Je publierai un paquet chocolaté pour NUnit 2.6.4, qui ressemblera à peu près à celui qui existe déjà pour 2.6.3.

Pour la version majeure, les choses peuvent changer. En général, nous essayons de nous éloigner des installateurs massifs qui installent tout au profit de packages plus petits interdépendants - à peu près dans le style de l'emballage apt.

En réponse à vos questions :

• En plus de chocolatey, nous avons des zips binaires, des programmes d'installation Windows et des packages nuget. Nous n'avons pas encore d'interface graphique, mais elle sera emballée séparément lorsque nous le ferons. Les packages que vous voyez actuellement dans la version bêta ne sont certainement pas le dernier mot : certains d'entre eux peuvent être divisés et de nouveaux seront certainement ajoutés.
• Je ne suis pas sûr de comprendre ce que vous entendez par "garder les packages Chocolatey synchronisés". Il est fort probable que le packaging 3.0 ne corresponde pas à ce qui existe actuellement. L'une des raisons pour lesquelles nous n'avons pas encore travaillé sur ce problème est que nous n'avons même pas finalisé les gouttes et msis binaires que nous allons produire. Dans la conception originale, la console, le moteur et le cadre devaient être complètement séparés. Jusqu'à présent, nous les avons conservés ensemble tout au long des versions bêta, car cela facilite grandement leur travail à ce stade de la conception. Ils sont destinés à être versionnés et publiés séparément, à condition que nous puissions surmonter certains obstacles.
• La réponse à votre dernière question est "Ça dépend". :-)

Je suis encore à peu près dans le noir sur le chocolat. J'espère apprendre à le connaître en travaillant sur le package 2.6.4. J'ai entendu dire qu'il prend en charge les méta-paquets - des packages qui en tirent simplement d'autres. Prend-il également en charge les packages virtuels - c'est-à-dire les dépendances pouvant être satisfaites par un ou plusieurs packages réels ?

@CharliePoole ,

Le package NUnit doit devenir le package virtuel. Les packages portables sont une nomenclature chocolatée pour "bin deploy". Les packages d'installation désignent un programme d'installation de Windows sous les couvertures.

Je _ne_ recommande pas_ de créer un package NUnit3 séparé dans Chocolatey. Si nous le faisions, les utilisateurs dépendraient du package "nunit" pour installer la série 2x et de "nunit3" pour installer la dernière version. Les utilisateurs peuvent compter facilement et de manière fiable sur le serveur.

Si je veux installer...

• NUnit2 : choco installe nunit -version 2.*
• Le dernier NUnit : choco install nunit
• Un NUni3 spécifique : choco install nunit -version 3.0.0-beta.1

À droite. Mais cela ne fonctionne que si les packages sous-jacents installés suivent la même structure que NUnit 2.x. Si, par exemple, il n'y a pas de gros programme d'installation Windows à tout faire à référencer, alors il ne peut pas y avoir un tel package dans Chocolatey.

Étant donné que NUnit 3.0 n'est pas entièrement rétrocompatible avec NUnit 2.x, de par sa conception, il semble être une mauvaise idée pour les utilisateurs d'obtenir une mise à niveau automatique à tout moment.

Cela dit, il vaut probablement mieux attendre pour en discuter jusqu'à ce que
1) Nous savons quelle sera la structure du package sous-jacent de NUnit 3.0, et
2) J'en sais plus sur Chocolatey. :-)

Essentiellement, c'est pourquoi c'est dans le jalon 3.0, ce qui signifie que nous ne prévoyons pas de le faire avant la fin de toutes les bêtas.

Voulons-nous toujours faire cela?

Il semble que les packages actuels soient collectés automatiquement en grattant nunit.org. (Lequel d'ailleurs est tombé en panne pour la version 3.4.1, la page nunit.org/download était-elle toujours liée à GitHub, ou est-ce nouveau ?) Cela semble être quelque chose que nous pourrions éviter si nous l'avions comme flux.

Il existe actuellement 3 packages nunit, avec environ 15 000 téléchargements, il est donc largement utilisé. Cela ne me dérangerait pas d'y jeter un coup d'œil, une fois que le programme d'installation se trouve dans un nouveau référentiel ?

@ChrisMaddock Chocolatey utilise un processus automatisé pour produire ce qu'il produit. Je n'avais jamais réalisé que cela grattait notre site Web. Cela ressemble à une approche qui pourrait facilement casser. Étant donné que je viens d'apporter des modifications à la page de téléchargement, je ne suis pas surpris qu'elle se soit cassée.

J'ai essayé de trouver quelque chose avec les gens qui faisaient l'emballage chocolaté et en fait ils m'ont ajouté comme l'un des emballeurs. J'ai pensé que cela nous donnerait au moins une certaine influence et que nous pourrions finalement faire nous-mêmes l'emballage du chocolat. Ils continuent cependant à conditionner le msi, même si je leur ai dit à l'époque que nous allions nous en débarrasser.

Il est assez normal dans le monde Linux open source que les conditionneurs fassent ce qu'ils pensent que leurs utilisateurs veulent et que les développeurs en amont n'ont pas grand-chose à dire à ce sujet. Il semblait que les chocolatiers importaient également cette structure dans Windows.

Cependant, il se peut que je les ai abandonnés trop facilement. Vous pouvez vous attribuer ce problème et l'essayer.

PS : je ne connais que deux packages, le V2 et le V3 msis. C'est quoi le troisième ?

Je ne connais que deux packages, le V2 et le V3 msis. C'est quoi le troisième ?

Ils packagent actuellement le msi, le .zip (que nous n'aurons plus) et un "méta-paquet", qui pointe vers le msi sous le nom "NUnit" (par opposition à "NUnit (installer)"). Ceux-ci sont tous disponibles pour les versions 2.6.4 et 3.X.

Je pense que nous devrions continuer les deux - je suppose, sinon msi, nous continuerons à avoir une sorte d'installateur. Le zip pourrait simplement contenir le moteur/la console/les compléments, c'est-à-dire qu'est-ce qui serait installé par l'installateur ? Cela signifie que NuGet reste la distribution principale du framework.

D'accord, c'est logique. Notez que nous n'arrêtons pas le zip, bien que son contenu change.

Mon point de vue est que nous n'emballons rien de spécial pour le chocolat. Nous déterminons simplement les combinaisons de choses dont nos utilisateurs ont besoin et créons ces packages. Nous avons juste besoin de reculer un peu lorsque les utilisateurs veulent simplement un certain type de package par habitude. Je pense que le framework et le coureur combinés sont l'une de ces choses, à l'exception du cas d'un package « démarrage avec nunit », si nous devons éventuellement en faire un.

La chose importante pour nous, je crois, est de reconnaître la même chose que les chocolatiers ont reconnue : les packs d'emballage sont différents du développement du logiciel en premier lieu et il est préférable de le faire séparément.

Chocolatey n'est-il pas basé sur NuGet ? Ne serait-il pas logique d'utiliser l'un des packages NUnit NuGet plutôt qu'un script ? Avis de non-responsabilité, je ne connais pratiquement rien à Chocolatey. :clin d'œil:

Tout cela est assez académique si nous ne pouvons avoir aucune influence sur ce que font les chocolatiers.

Je pense que les packages chocolatey doivent être emballés différemment car ils ont des scripts d'installation indépendants différents. (Je suppose que ceux générés par défaut feraient tout ce dont nous avons besoin, nous devrons vérifier.) Mais ils utilisent des fichiers nuspec, il peut donc être possible de les partager, avec quelques extras supplémentaires pour chocolatey.

Bon point cependant, ce serait bien si le contenu de la version portable reflète le package NuGet de NUnit.Runners. Moins à suivre !

Quelques petites notes puisque cela fait plus d'un an.

Les packages NUnit portables (installation bin) et complets peuvent être conditionnés pour Chocolatey avec le fichier .zip/.msi inclus dans le package ou une URL permanente pour télécharger le package. Dans d'autres projets, j'ai utilisé l'URL de version Github pour télécharger dynamiquement le package approprié.

À @CharliePoole , si le package nunit est un métapackage, notez que Chocolatey ne met rien à jour automatiquement. Les utilisateurs doivent spécifier qu'ils souhaitent mettre à jour aveuglément les packages vers la dernière version ou créer un fichier packages.config et s'assurer que des _versions_ spécifiques du package sont installées.

Je recommande toujours un métapackage NUnit afin que d'autres packages puissent dépendre de n'importe quelle version de NUnit installée et avoir ensuite des packages spécifiques pour les versions individuelles. Ce n'est pas différent de l'utilisation d'apt-get/brew install nodejs et il installe la dernière version au lieu de spécifier une version spécifique dont vous avez besoin.

@DustinVenegas Je ne sais pas ce que vous entendez par les packages portables par rapport aux packages complets. Nous avons une version de framework portable, mais elle n'est pas emballée séparément des autres versions. Seuls les cadres silverlight et compact sont livrés dans des emballages séparés. Je suis tout à fait d'accord pour dire qu'ils devraient utiliser l'URL github pour obtenir les packages, et non gratter les pages du site Web, qui peuvent toujours changer. Cependant, je dis « ils » parce que ce n'est pas sous notre contrôle.

Je suis d'accord qu'un méta-emballage est la voie à suivre, mais encore une fois, c'est légèrement hors de notre contrôle puisque nous ne faisons pas l'emballage chocolaté. Je pense à notre paquet nuget NUnit.Console comme une approximation d'un métapaquet, dans les limites de ce que nuget prend en charge, mais cela ne ressemble en rien à la puissance d'un métapaquet dans le monde d'apt-get.

Existe-t-il un moyen de commencer à fabriquer nous-mêmes un emballage chocolaté, indépendamment des personnes de chocolatey.org ?

@CharliePoole - Chocolatey fait référence aux packages sans programme d'installation comme portables - sans rapport avec .NET portable. Le package nunit.portable actuel ne contient que les versions .zip NUnit, par opposition à nunit.install qui est le msi.

Chocolatey.org semble généralement désireux que les fournisseurs de logiciels maintiennent leurs propres packages, j'espère donc que nous pourrions trouver quelque chose pour reprendre les packages existants - bien que d'après votre expérience, il semble que cela ne soit pas aussi fluide que prévu. J'avais l'intention de prendre contact après la finalisation du # 1716, et maintenant probablement après mon absence - cependant, si quelqu'un veut le faire plus tôt, il est le bienvenu pour prendre le relais. :le sourire:

Je recommande toujours un métapaquet NUnit afin que d'autres paquets puissent dépendre de n'importe quelle version de NUnit

@DustinVenegas - Pouvez-vous clarifier ce que vous voulez dire ici ? Le lien ci-dessous est le méta-paquet NUnit actuel (par les gars chocolatés) - il me semble que cela passe simplement par une version spécifique du package d'installation ? À quel moment le métapaquet vous permet-il de « dépendre de n'importe quelle version » que nunit.install ne fait pas ?

https://github.com/dtgm/chocolatey-packages/blob/master/automatic/nunit/nunit.nuspec

Je ne prétends pas non plus être un expert en chocolat !

@CharliePool ,
Vous êtes répertorié sur le package Chocolatey NUnit . @dtgm est assez responsable et acceptera probablement un PR ou nous pouvons lui demander d'arrêter tous les packages automatiques et cela pourrait être inclus dans le processus de publication. J'ai fait quelque chose de similaire pour Carnac. Le canal « Contacter les administrateurs du site » ou Gitter sont également de bons endroits pour demander.

@ChrisMaddock ,
Vous avez raison de dire que les métapaquets n'autorisent rien de spécial pour le moment. Chocolatey est toujours en train de finaliser des "paquets virtuels", qui permettraient à nunit.portable _ou_ nunit.install de remplir la dépendance nunit. Pour le moment, créer ce que Chocolatey appelle des métapaquets est la bonne méthodologie à suivre pour s'y préparer.

Pour rencontrer @CharliePoole souhaitant @dtgm ou de prendre en charge le processus nous-mêmes. Le métapaquet, nunit , doit contenir les versions v2 et v3 et doit dépendre du paquet nunit.portable de la même version. Les consommateurs finaux accèdent facilement à choco install nunit --version 2.x.x pour construire des serveurs/machines de développement. D'autres packages dépendent de <dependency name="nunit" version="3.x.x" /> qui seront remplis par le programme d'installation ou les packages portables à l'avenir.

@DustinVenegas Oui... Je suis revenu sur la liste alors que j'espérais pouvoir prendre le relais... les gens de Chocolatey étaient très accueillants de cette façon et ont ajouté mon nom. Ils ne voulaient tout simplement pas suivre mes conseils, donc avoir mon nom là-bas est purement honorifique. :-)

Pour être clair, je ne me suis pas offusqué. Il s'agit d'un type de désaccord assez courant entre les packageurs et les développeurs en amont dans le monde Linux, il n'est donc pas surprenant de le voir ici.

Si nous pouvions proposer des packages alternatifs pour Chocolatey, alors je pense qu'il serait temps de reprendre la discussion. Quelqu'un qui s'intéresse à la création de tels packages doit s'occuper de ce problème.

Un point... Votre suggestion de créer un métapaquet qui couvre à la fois NUnit 2 et 3 semble incorrecte. Je ne vois aucune exigence qui pourrait être satisfaite par _soit_ NUnit V2 ou NUnit V3. Ce sont des produits incompatibles au niveau de l'interface. Pouvez-vous donner un exemple de quelque chose qui pourrait dépendre d'un tel métapaquet ?

@CharliePoole ,

Les développeurs de Chocolatey ont été très accueillants. Si vous souhaitez prendre le contrôle total de l'emballage, contactez @ferventcoder sur Gitter, ou le lien Contact Admins devrait être le plus simple.

Maintenant, concernant le métapaquet. En tant qu'utilisateur final de Chocolatey, je m'attends choco install package ce que nunit-2.6.* qui installerait la dernière version 2.6. Si je créais un package, je pourrais dépendre de n'importe quoi nunit-3.2.* ou d'une version plus spécifique.

Le métapaquet ressemble et fonctionne exactement de la même manière que le (paquet Nuget)[https://www.nuget.org/packages/NUnit/] où le semver est suffisant pour indiquer des changements de rupture. Ils sont juste un moyen pour nunit.portable v2.0.2 _ou_ nunit.install v2.0.2 de répondre à l'exigence nunit v2.0.2. Cela me permet également d'installer plusieurs versions différentes du même package simultanément.

Puisque vous essayez de vous débarrasser du programme d'installation, il peut suffire de publier les installations portables (bin) dans le package nunit. Cela dit, toute mon automatisation dépend actuellement de nunit 3.2.1, qui est par défaut le programme d'installation. Cela pourrait être intéressant.

@DustinVenegas Comme je l'ai dit, ils m'ont également accueilli. Nous ne pouvions tout simplement pas nous mettre d'accord sur ce qu'ils voulaient emballer.

J'ai déjà eu de nombreux contacts avec les personnes mêmes que vous suggérez que je parle. Ils ont clairement indiqué qu'ils ne voulaient pas changer ce qu'ils faisaient. C'est pourquoi je vous ai demandé s'il était possible de créer des emballages sous forme chocolatée, sans leur implication.

Je pense que vous et moi devrons simplement convenir d'être en désaccord sur la facilité de travailler avec les gars chocolatés.

En ce qui concerne le métapaquet, je suppose que c'est raisonnable, selon ce que vous entendez par "prendre une dépendance sur nunit". Il n'y a qu'un seul nom d'assembly en commun entre v2 et v3.

Ils ne voulaient tout simplement pas suivre mes conseils, donc avoir mon nom là-bas est purement honorifique. :-)

@CharliePoole en fait, nous vous avons ajouté dans l'espoir que vous commenceriez à publier des packages. Voici la conversation originale pour les autres - https://chocolatey.org/packages/nunit#comment -1840892100. C'était il y a environ un an. Pendant ce temps, il n'y a pas eu beaucoup de mouvement de la part des gens de NUnit pour publier des packages ou demander à @dtgm d'arrêter de publier des versions utilisant l'empaquetage automatique afin que vous puissiez (du moins pas à ma connaissance).

C'est très bien si vous voulez aller de l'avant avec la publication de packages sur le référentiel de la communauté et nous sommes extrêmement heureux de cela. Cependant, en comprenant les différences entre NuGet et Chocolatey, vous réfléchissez peut-être un peu aux choses. Vous pouvez maintenant installer NUnit.Runners en tant que package Chocolatey - choco install nunit.runners --source https://www.nuget.org/api/v2/ . Alors que Chocolatey a un certain nombre de fonctionnalités supplémentaires dans la façon dont il peut rassembler des binaires, c'est toujours aussi simple que d'avoir les binaires d'exécution dans le package lui-même. En règle générale, les personnes qui ne sont pas les fournisseurs de logiciels n'ont pas de droits de distribution sur le logiciel et doivent le télécharger à partir d'un emplacement distant.

Sortie de cette commande au fait :

Ils ont clairement indiqué qu'ils ne voulaient pas changer ce qu'ils faisaient. C'est pourquoi je vous ai demandé s'il était possible de créer des emballages sous forme chocolatée, sans leur implication.

@CharliePoole Je ne suis pas sûr de dire que les emballeurs actuels "ont clairement indiqué qu'ils ne voulaient pas changer". Je ne sais pas s'il s'agit d'une mauvaise communication ou d'une incompréhension de ce qui a été communiqué, j'ai vu un dialogue sain sur la façon dont cela se faisait actuellement , avec des questions sur la façon dont vous le verriez abordé pour la v3 - https://chocolatey.org/packages /nunit#comment -2120088484.

En ce qui concerne la 3.0, vous voudrez changer le nom tel qu'il est enregistré dans le registre pour quelque chose de différent de la série 2.x. Sinon, la version 3.0 devrait être publiée sous le même nom de package, sinon des conflits surviendront lors de l'installation/de la désinstallation, car deux packages ne devraient pas partager un nom de registre commun. Si quelqu'un souhaite installer une ancienne version de nunit, il peut toujours spécifier '-version 2.6.4' et 'choco pin'.

J'ai lu cela comme des suggestions sur la façon dont vous feriez probablement les choses pour publier la v3 en tant que package séparé (car c'est ce que vous aviez indiqué ce que vous vouliez faire dans les commentaires avant celui-ci) ou laisser la v3 se produire avec le "nunit" actuel paquet et que se passerait-il si aucune décision n'était prise par vous.

Je n'ai également que cette conversation à poursuivre, donc je ne sais pas s'il y a eu d'autres communications de la part des mainteneurs actuels où il a été clairement indiqué plus tard que ces mainteneurs ne veulent pas que les choses changent. S'il vous plaît, faites-moi savoir?

Juste pour noter, je me suis désaffecté car je suis absent pendant un certain temps, et il semble que cela commence à bouger. J'espère que quelque chose peut être réglé ! :le sourire:

@ChrisMaddock Je marque en fait ceci comme bloqué. La raison en est que je me suis rafraîchi la mémoire de la discussion d'il y a un an et j'ai réalisé que les installations de Chocolatey sont toujours basées sur nos installations. Il me semble que nous ne devrions pas multiplier les formats de nos packages tant que nous n'avons pas fermement décidé ce qui sera emballé et publié.

Cette décision concernant la granularité du package est en suspens depuis la version 3.0 et nous venons juste de commencer à apporter un certain nombre de grands changements avec la séparation du framework de la console/du moteur. Je pense que nous devons avoir une liste des packages que nous publions avant de pouvoir décider lesquels de ces packages devraient être sur chocolatey. En fait, la discussion d'il y a un an portait principalement sur le fait de ne pas vouloir d'une version chocolatée pour un package que nous avions prévu d'arrêter et que nous venons d'arrêter. Je vais commenter séparément à ce sujet.

Je pense que @DustinVenegas envisage l'approche d'un logiciel == un package, où les versions sont traitées comme une préoccupation du package. L'emballage n'est pas une « approche unique », car les logiciels sont de toutes formes et tailles et permettent différentes approches.

Dans les cas de logiciels où plusieurs versions peuvent être installées en même temps, comme .NET Framework 2.x par rapport à .NET Framework 4.x, ou avec Ruby sur plusieurs versions, nous voyons plusieurs noms de packages pour ces éléments. Si NUnit v3 existe sur une machine en même temps que NUnit v2 (ou même plusieurs versions de chacune), vous pouvez avoir plusieurs approches pour l'empaquetage, où vous avez soit quelqu'un qui utilise des installations côte à côte pour plusieurs versions du même identifiant de package, ou vous utilisez des noms de packages différents. Il est vraiment difficile de dire si les changements de rupture impliquent l'utilisation de noms de packages différents.

Packages Puppet et Puppet-Agent - même logiciel, packages différents

Voici un cas à considérer :

• https://chocolatey.org/packages/puppet
• https://chocolatey.org/packages/puppet-agent

Puppet contre Puppet-Agent. Ou la prise en compte de Puppet jusqu'à et y compris la v3 et Puppet à 4.x+. L'équipe Puppet a décidé de créer de nouveaux packages pour Puppet-Agent (v4+) alors qu'elle passait à une approche omnibus (regroupant ruby ​​et tous les outils dans le package). Alors que cela était déjà fait pour Puppet sous Windows, nous voulions maintenir la parité avec les noms de packages sur toutes les plates-formes de système d'exploitation, donc Chocolatey a emboîté le pas à ce qui a été fait pour les autres gestionnaires de packages.

Ruby - même package pour toutes les versions, mais aussi un package pour chaque majeure

Autre cas à considérer :

• https://chocolatey.org/packages/ruby

Le package ruby ​​regroupe actuellement tout. Nous avons également pensé à créer un package ruby ​​par version majeure (1.9.x, 2.0.0, 2.1.x, 2.3.x, etc.) qui permet aux utilisateurs d'avoir plus de choix lorsqu'il s'agit d'installer Ruby. Ceci est également plus comparable à la façon dont l'empaquetage est fait pour Ruby sur d'autres plates-formes de système d'exploitation.

L'un ou l'autre (ou quelque chose d'autre) pourrait être une considération pour ce que vous pouvez faire. :)

Vous avez des options

Je suppose que ce que j'essaie de dire, c'est que vous avez des options. Quand les gens expliquent le statu quo, ou même quand une seule personne vous dit comment vous devez faire les choses (même si c'est moi), je vous demande de ne pas considérer cela comme quelqu'un qui indique clairement que la communauté Chocolatey ne veut pas changer. Les choses sont fluides et rapides avec la communauté Chocolatey et vous voyez probablement des changements plus rapidement qu'avec d'autres gestionnaires de packages.

@ferventcoder Salut Rob ! Je suppose que tu as "entendu" ton nom. :-)

Depuis mon dernier message, j'ai passé en revue toutes les discussions, qui étaient à environ trois endroits différents. En les regardant avec les yeux d'aujourd'hui, j'ai réalisé plusieurs choses...

1. Les gens à qui je parlais ne sont pas tous des « gars du chocolat ». Certains d'entre eux sont en fait des contributeurs communautaires. Ce n'était pas clair pour moi à l'époque. En particulier, j'avais l'impression que le gars avec quelque 900 paquets libérés automatiquement faisait partie du projet chocolatey, alors j'attribuai son désir de continuer à le faire à chocolatey. D'une manière ou d'une autre, en relisant, il a juste cliqué... chocolatey permet aux membres de la communauté d'empaqueter des versions de logiciels dont ils ne sont pas l'auteur ! C'est probablement évident de votre point de vue, mais je n'ai pas compris.
2. Je ne me souviens pas si c'était dans la discussion publique ou dans un e-mail séparé, mais en communiquant avec le mainteneur, j'ai demandé s'il avait l'intention de continuer à publier la version automatique de NUnit pour NUnit 3, que j'ai préféré prendre en charge. Il a dit qu'il l'a fait bien qu'il m'ait invité à soumettre des PR à son repo personnel. Ce genre de clos le problème pour moi. En partie, cela a peut-être semblé définitif parce que je le considérais comme faisant partie de l'infrastructure chocolatée à l'époque. Mais surtout, je sentais qu'il avait le droit de publier ses propres packages de NUnit dans les termes de notre licence, que cela nous plaise ou non.
3. Nous savons depuis le jour 1 de NUnit 3 que les jours du "maître" nunit msi étaient comptés. Nous le gardions pour la compatibilité et, franchement, nous l'avons déjà gardé trop longtemps. C'est parti maintenant. Il y aura un msi pour la prochaine version de NUnit, mais il n'inclura pas le framework. Je ne pense pas que ce soit une grande perte pour les utilisateurs de chocolat, même s'il faudra l'expliquer. Étant donné que le framework est une bibliothèque, je pense qu'il est préférable de le gérer projet par projet via nuget.
4. À l'époque, et je pense que cela continue à travers le présent, le site de la communauté ne contenait qu'un seul package pour NUnit, les distinguant à travers les versions. Comme vous le savez, nous avons pris la décision de traiter NUnit 3 comme un package distinct de NUnit 2, exception faite uniquement pour le framework. Traiter les deux programmes différents comme un seul paquet semble superficiellement pratique pour les utilisateurs, mais en pratique conduit à toutes sortes de confusions lorsqu'ils ne fonctionnent pas de la même manière. J'ai proposé de prendre le relais avec un package NUnit 3 séparé, mais cette offre a semblé être refusée. En relisant les messages et les courriels, je suppose que cela n'a probablement pas été compris.
5. Je tiens à souligner à nouveau que vous et le mainteneur actuel m'ont très bien traité dans cette discussion vieille d'un an. Si j'avais l'air de fulminer un peu, c'était contre le commentateur qui semblait vouloir que je recommence.

En bout de ligne... J'ai dit que je voulais que nous maintenions l'installation chocolatée pour NUnit 3. J'ai demandé au mainteneur actuel s'il prévoyait de faire NUnit 3 ainsi que NUnit 2. Il a dit oui et j'ai reculé pour éviter un conflit.

Ironiquement, j'étais en fait prêt à abandonner ce problème dans le cadre du nettoyage lorsque @ChrisMaddock et @DustinVenegas ont commencé à le commenter activement. Il s'agissait d'un problème généré en interne - aucun utilisateur n'a demandé d'installation de choco. OTOH, j'aime l'idée d'utiliser chocolatey pour les outils et de laisser tomber complètement msis, afin que nous puissions continuer à en parler pendant un certain temps.

Je viens de recevoir un autre commentaire de votre part... Je vais y répondre séparément.

Les packages

Je suis content que vous voyiez des options. :-)

Je pense que l'utilisation de deux versions du même package devrait impliquer que l'utilisateur obtienne la même fonctionnalité globale dans les deux packages. Nous n'avons pas toujours bien fait, mais j'aimerais que nous nous améliorions.

Voici ce que je veux dire...

NUnit V2 a un msi qui inclut

• La dernière version du framework nunit
• Coureur de console NUnit
• NUnit gui runner
• Agents NUnit utilisés hors processus
• bibliothèques utilisées par les deux coureurs

En utilisant ce package, un utilisateur peut

• Ecrire des tests, en référençant le framework
• Exécuter des tests sous la console d'exécution
• Exécuter des tests sous le gui runner

NUnit V3 a un msi qui inclut

• NUnit Console d'exécution
• Moteur NUnit (y compris les agents)

En utilisant ce package, l'utilisateur peut

• Exécuter des tests sous la console d'exécution
• Exécuter des tests par programme à l'aide du moteur

Avoir un nom de package mais dire aux utilisateurs qu'ils ne peuvent plus faire certaines choses avec la nouvelle version mais qu'ils ont d'autres choses à faire s'avère plutôt difficile.

J'apprécie votre commentaire sur le fait de ne pas trop faire attention lorsque les gens nous disent comment nous devrions faire les choses - ou dans ce cas comment nous aurions dû faire les choses. Malheureusement, j'appliquais cela à l'envers et je pensais qu'il n'y avait aucun moyen d'amener le conditionneur à prêter attention à mes opinions. :-(

Seriez-vous d'accord avec ma déclaration précédente selon laquelle aucun travail ne devrait être fait sur cette question jusqu'à ce que nous ayons réellement confirmé les packages que nous prévoyons de produire ?

Seriez-vous d'accord avec ma déclaration précédente selon laquelle aucun travail ne devrait être fait sur cette question jusqu'à ce que nous ayons réellement confirmé les packages que nous prévoyons de produire ?

Je serais d'accord avec ça. Difficile de connaître votre chemin à suivre sans un plan. ??

Nous pouvons contribuer à cela en tant que processus collaboratif, être principalement passifs et simplement valider que tout va bien avec ce que vous voulez faire, ou vous pouvez finalement soumettre des packages à la communauté et nous pouvons partir de là. Ma recommandation est l'une des deux premières approches. Vous aurez la meilleure idée de ce que vous voulez faire ici en ce qui concerne les packages.

Une exigence de dépendance - Chocolatey Framework

La seule chose actuellement ferme en ce qui concerne l'empaquetage est les dépendances - les dépendances sont l'application au niveau de l'application, pas au niveau de la DLL. Une unité respective (un emballage) doit contenir tous les assemblages requis qu'elle doit utiliser. Supposons donc que vous ayez un package appelé "nunit-agent" avec "nunit-agent.exe" inclus. Si nunit-agent.exe requiert nunit.dll, alors nunit.dll doit également être présent dans ce package.

Lorsque vous dites « il doit être utilisé », je suppose que vous voulez dire « il a besoin pour fonctionner » plutôt que « en bénéficierait probablement ».

Par exemple... si vous installez le framework nunit (paquet nunit), vous pouvez construire des tests avec. Si vous voulez réellement exécuter ces tests, vous avez besoin d'une sorte de coureur. Ce coureur peut être la console, l'interface graphique, l'adaptateur VS ou quelque chose que vous écrivez vous-même. J'appellerais cela une "suggestion" plutôt qu'une dépendance et je ne m'attendrais pas à ce que chocolatey en prenne note.

Si vous installez le package console/moteur (nous prévoyons actuellement de les garder ensemble), il est probable que vous vouliez une version (peut-être plusieurs versions) du framework nunit afin d'écrire des tests que vous exécuterez, mais ce n'est pas nécessaire . Encore une fois, je ne m'attendrais pas à ce que Chocolatey gère cela.

Dans ces cas, vous pouvez soit exécuter des tests écrits par quelqu'un d'autre, soit envoyer les tests ailleurs pour qu'ils soient exécutés - je sais que c'est exagéré, mais c'est possible.

OTOH, disons que vous installez l'interface graphique. L'interface graphique a besoin d'une version du moteur nunit pour être sur votre système quelque part afin de s'exécuter. La version fournie avec la console fera l'affaire, tout comme un package de moteur séparé s'il existe. Quelle relation voulez-vous dans ce cas ?

Lorsque vous dites « il doit être utilisé », je suppose que vous voulez dire « il a besoin pour fonctionner » plutôt que « en bénéficierait probablement ».

Oui, "pour s'exécuter" - une dépendance au niveau de l'assemblage.

OTOH, disons que vous installez l'interface graphique. L'interface graphique a besoin d'une version du moteur nunit pour être sur votre système quelque part afin de s'exécuter. La version fournie avec la console fera l'affaire, tout comme un package de moteur séparé s'il existe. Quelle relation voulez-vous dans ce cas ?

Si le moteur est un exécutable, package. Si le moteur est une DLL, c'est là que ça commence à devenir flou. Typiquement, cela signifie qu'il va dans chaque paquet qui en a besoin. Il n'est pas rare de voir log4net dans plusieurs packages.

Autres considérations:

• La version du moteur de la console peut-elle être différente de la version du moteur de l'interface graphique ?
• Si le moteur est un exécutable, est-il judicieux de l'empaqueter seul ? Est-ce que cela embrouillerait les gens de l'installer?

Le moteur est une DLL qui peut être utilisée par un coureur via une API. L'api est un assemblage séparé et est toujours emballé avec le coureur qui en a besoin. L'assembly api sait comment trouver un moteur, le charger et l'utiliser. Ainsi, le moteur ressemble vaguement à un service (windows) ou à un daimon (linux).

Les coureurs nécessitent généralement une version minimale du moteur. Les express qui en ont besoin lorsqu'ils demandent à l'API de charger un moteur. Ils peuvent également regrouper une copie du moteur local du moteur et l'API peut également gérer cela. De plus, certains exécuteurs peuvent en fait référencer le moteur, afin de contourner les limitations actuelles de l'assemblage d'API. L'adaptateur NUnit 3 fait cela.

Je pense que la dichotomie dll/exe est basée sur l'hypothèse que la seule façon d'utiliser une dll est de la référencer. Ainsi, la vraie distinction peut être entre les choses qui sont référencées et celles qui ne le sont pas.

Comme j'y pense... il peut être pertinent de voir s'il existe des services Windows installés en tant que packages chocolatés et comment ils sont structurés. Même s'il ne s'agit pas d'un service Windows, c'est toujours quelque chose qui est disponible pour une utilisation par plusieurs outils.

@nunit/core-team Je pense que cela appartient maintenant au projet nunit-console. Le package NUnit n'est que le framework libs et n'est pas idéal pour chocolatey. OTOH, nunit-console est un outil et il peut être installé de manière centralisée par les utilisateurs si nous créons un package chocolatey.

Si vous êtes d'accord - ou n'êtes pas d'accord dans un délai raisonnable - je propose cela. :le sourire:

@CharliePoole - a convenu que cela n'appartient pas ici, ne serait-ce pas un meilleur ajustement mis en œuvre dans la distribution nunit, étant donné que cela impliquera potentiellement la distribution à la fois du msi et d'un coureur portable avec des packages d'extension? En tout cas, ça ne m'inquiète pas trop !

@ChrisMaddock Si nous devions faire un package d'installation et un package portable, basés respectivement sur le msi et le zip, cela pourrait avoir un peu de sens. Même ainsi, ce n'est pas nécessaire car l'emballage chocolaté fait simplement référence à ces choses.

Cependant, je pense créer un package portable natif, basé sur nos packages NuGet. Les packages ne seraient que des références, il est donc facile de le faire dans le projet lui-même. Comme justification supplémentaire, je souhaite y travailler moi-même, ce qui a plus de sens dans le projet nunit-console.

@CharliePoole - d'accord, ce serait bien si les packages NuGet pouvaient être réutilisés. En ce qui concerne le package d'installation, il convient peut-être de noter que ce package a 15 000 à 25 000 téléchargements, contre seulement 350 pour le package portable. (15-25k, car je ne sais pas exactement comment ils s'empilent !) Quoi qu'il en soit, je pense qu'il y a certainement une demande pour un package d'installation.

Ma préférence générale lors de l'utilisation de chocolatey est d'opter pour les packages d'installation qui automatisent essentiellement l'exécution du programme d'installation - de cette façon, j'ai plus de confiance que le logiciel est installé exactement comme il l'aurait été auparavant lorsque je le faisais à la main, et Je devrais pouvoir éviter de déconner. Personnellement, j'aimerais voir le package d'installation conservé. Cependant, je peux voir comment les packages portables pourraient être considérablement améliorés par des options plus granulaires !

Salut chris,

Je ne sais pas pourquoi mais je reçois tous vos messages envoyés à @charliePool -
ils ne me sont pas destinés, vous voudrez peut-être vérifier Github.

Charlie

Piscine Charlie

0203 327 4762 / 07876 773 819
www.stowga.com
21 Dartmouth Street, Londres, SW1H 9BP

Le 7 décembre 2016 à 14:49:04, Chris Maddock ([email protected])
a écrit:

@CharliePoole https://github.com/CharliePoole - d'accord, ce serait bien si
les packages NuGet peuvent être réutilisés. Concernant le package d'installation, peut-être
à noter que ce package a 15 000 à 25 000 téléchargements, contre seulement
350 pour le forfait portable. (15-25k, car je ne sais pas exactement comment ils
stack !) Quoi qu'il en soit, je pense qu'il y a certainement une demande pour une installation
paquet.

Ma préférence générale lors de l'utilisation de chocolatey est d'opter pour l'installation
packages qui automatisent essentiellement l'exécution du programme d'installation -
de cette façon, j'ai plus de confiance que le logiciel est installé exactement comme il
aurait été auparavant quand je le faisais à la main, et je devrais être
capable d'éviter tout dérangement. Personnellement - j'aimerais voir le
package d'installation conservé. Je peux cependant les paquets portables pourraient être
considérablement amélioré par des options plus granulaires !

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/nuni/nunit/issues/452#issuecomment-265466082 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAvZpiyULPLMUNKYzYxRq-ErjVdvaiSCks5rFsdfgaJpZM4DQJtZ
.

@charliepool On dirait que github ou le serveur de messagerie nous

Je me demande si vous êtes le même charlie.poole sur gmail pour qui je reçois périodiquement des informations de différentes boutiques londoniennes. :le sourire:

Haha, ça pourrait bien être moi !

Le 7 décembre 2016 à 15:23:20, CharliePoole ([email protected])
a écrit:

@charliepool https://github.com/charliepool On dirait github ou le courrier
le serveur nous embrouille.

Je me demande si tu es le même charlie.poole sur gmail pour qui je reçois
informations périodiquement de divers magasins de Londres. ??

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/nuni/nunit/issues/452#issuecomment-265475613 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAvZpkMaL8QzLvgmwJSHOJ4VNJ11MOrSks5rFs9fgaJpZM4DQJtZ
.

Piscine Charlie

0203 327 4762 / 07876 773 819
www.stowga.com
21 Dartmouth Street, Londres, SW1H 9BP
@ctapool https://twitter.com/ctapool @stowga https://medium.com/stowga

Excuses Charlie et Charlie - J'arrêterai d'utiliser le @ pour le moment !

@ChrisMaddock @rprouse Cela fait un moment que ça dure et c'est maintenant l'un des deux problèmes de framework ouverts qui me restent assignés.

J'avais l'impression que nous avions déjà publié nunit-console via chocolatey. Ce n'est pas le cas. J'ai publié l'éditeur de projet NUnit comme un exercice pour apprendre comment fonctionne le chocolat et j'avais l'intention de passer à la console, mais d'autres choses sont apparues. En fait, il n'y a aucun problème pour créer un package chocolaté pour la console - juste celui-ci.

Il y a beaucoup de discussions sur ce fil, donc je vais résumer ce que nous devons faire...

1. Créez un ou plusieurs packages Chocolatey pour la console. Je vais créer ce problème dans le dépôt de la console.

2. D'une manière ou d'une autre, signalez l'ancien emballage chocolaté NUnit comme obsolète et n'est plus maintenu. Cela peut être contrôlé par ce problème.

La seule chose qui reste à faire ici est de déprécier le package nunit existant sur chocolatey, qui est basé sur un package que nous avons arrêté de produire après la 3.4. J'ai déposé un problème sur dgtm/chocolatey-packages pour le nettoyer et je publierai une nouvelle version de l'ancien package qui désapprouve son utilisation.

Bloqué jusqu'à ce que nous ayons un package auquel nous pouvons référer les utilisateurs lorsque celui-ci est obsolète.

@CharliePoole - Je pense que nous avons pris la décision explicite de ne pas mettre le cadre sur choco, n'est-ce pas ? Pouvons-nous clore ce problème ?

Le sens de ce problème a progressivement changé pour supprimer ou déprécier l'emballage chocolaté existant - que nous n'avons pas écrit. Je l'ai marqué en bloc, car le déprécier signifie que nous devons dire aux gens ce qu'ils doivent utiliser. Je peux vérifier cela pour voir si cela peut être débloqué et complété.

J'admets que c'est déroutant lorsqu'un problème change de sens pour devenir l'inverse de ce qu'il a dit à l'origine, mais nous __serons__ ajouterons un package lorsque nous déprécions l'ancien. ??

mais nous ajouterons un package lorsque nous déprécierons l'ancien.

Juste pour clarifier, vous voulez dire que nous prévoyons d'ajouter un package cadre à chocolatey ? Je pensais que nous avions depuis décidé d'avoir le framework uniquement sur NuGet, et juste les coureurs sur choco.

Il y a un vieux paquet, pas écrit par nous sur Chocolatey, basé sur le msi. Il n'a pas été mis à jour depuis longtemps, car il a été créé automatiquement, chaque fois que nous avons publié nunit.msi. J'ai le pouvoir de le mettre à jour et je le mettrais à jour avec un package obsolète, qui indique aux utilisateurs ce qu'ils peuvent maintenant faire plutôt que d'utiliser l'ancien. Vous ne voulez jamais supprimer un ancien package, mettez-le simplement à jour pour supprimer tout le code et dites aux utilisateurs de ne pas l'utiliser. Chocolatey a un ensemble de conventions autour de cela.

Ce qu'ils peuvent maintenant faire, c'est obtenir le package nunit-console ou nunit-console-runner. Le blocage du problème attendait ces packages. Je dois vérifier si nous sommes prêts à pointer vers ces packages maintenant. Je pense que oui, mais j'ai un léger doute sur le fait que nous attendons peut-être la prochaine version de la console.

Ah ok. Je pensais que vous vouliez dire que vous prévoyiez un package _framework_ de remplacement - ce qui était une nouvelle pour moi ! ??

J'ai changé le titre pour (espérons-le) éviter toute confusion.

Après examen, voici ce qu'il reste à faire.

1. Publiez le dernier package nunit-console pour chocolatey, en dépréciant toutes les versions portables ou d'installation précédentes.

2. Dépréciez les packages nunit existants, en vous référant à la version nunit-console, qui est la plus proche en contenu même si elle ne contient pas le framework.

Qui est en mesure de les assumer ?

Je suppose que vous proposez mon retrait ?

Bonté, non. Je cherchais à répartir la charge mais je ne sais pas qui a accès à Chocolatey. Rétrospectivement, j'aurais probablement dû regarder si ce problème était attribué à quelqu'un. De cette façon, j'aurais réalisé que ce n'était pas quelque chose que vous attendiez que l'équipe fasse.

Au lieu de demander des informations, j'aurais dû dire ce qui m'importe vraiment : est-ce que je peux faire quelque chose pour aider ?

Cela ne semble plus être bloqué, j'ai donc supprimé l'étiquette.

Étant donné que je ne suis plus impliqué dans les versions de packages, je supprime également mon affectation.

@CharliePoole - pour autant que je résoudre ce problème sans y accéder - devrait- @rprouse en tant que mainteneur, alors que ce problème reste ouvert ?

Pour info - les quatre extensions de moteur gérées par l'organisation semblent également être sous votre compte, je ne sais pas s'il serait judicieux d'ajouter Rob à celles-ci en même temps, si vous cherchez à mettre fin à votre implication dans les versions de packages. (Sauf si vous êtes intéressé à entretenir un couple ?? 😛)

Aussi, cela s'est passé il y a quelques mois : https://blog.nuget.org/20180417/organizations-on-nuget-org.html

@ChrisMaddock Ah ! J'ai oublié cela. Laissez-moi regarder à nouveau et découvrir ce qui est possible. Je ne sais pas si j'ai les mêmes droits en tant que mainteneur pour ajouter quelqu'un ou si seul le mainteneur d'origine de ce paquet a le droit. Dans tous les cas, il est probablement poli de lui demander. Nous aurions besoin de décider qui est responsable de ces paquets. Si c'est Rob, alors je pense que tout mouvement vers un projet NUnit plus décentralisé est à peu près terminé.

J'ai aussi oublié que je suis le seul à maintenir les extensions. Je vais devoir regarder en arrière pour me rappeler comment les dernières versions ont été gérées. Personne n'est jamais devenu chef de projet pour les extensions, donc je ne sais pas qui a sorti chacune d'entre elles en dernier. J'aurais pu le faire à la demande de quelqu'un, je suppose.

Je pense que vous savez déjà que j'avais voulu rester dans l'équipe et mener certains projets, mais cela n'a pas fonctionné comme je le souhaitais. Beaucoup d'eau a coulé sous ce pont particulier maintenant. Dans tous les cas, je pense qu'une discussion plus approfondie devrait être entre les membres de l'équipe et généralement pas publique à ce stade.

@jnm2 Je ne l'ai pas remarqué. Je vais l'utiliser pour mes projets !

Merci Charlie, ça sonne bien. Pour info, je crois que le mainteneur d'origine, @dtgm a pris du recul par rapport à sa vaste gamme de paquets chocolatés maintenant - et @gep13 fait ce qu'il peut pour aider à maintenir les choses à jour.

Je n'ai pas pu trouver de source plus officielle de cette mémoire que celle-ci - mais je suis à peu près sûr que enlevions quelques -

Nous aurions besoin de décider qui est responsable de ces paquets. Si c'est Rob, alors je pense que tout mouvement vers un projet NUnit plus décentralisé est à peu près terminé.

Je suis d'accord sur le long terme, nous voulons une responsabilité 'compte organisation'. À court terme, comme Rob est déjà le compte sur un seul paquet, il semblait logique de les garder ensemble !

@ChrisMaddock yip, vous avez à peu près résumé cela exactement. Si vous pouvez me faire connaître le nom d'utilisateur du compte que vous souhaitez ajouter en tant que mainteneur de quels packages, je peux le faire pour vous. @dtgm a clairement indiqué que toute aide pouvant être offerte pour la maintenance des packages serait reçue avec reconnaissance, et j'ai un accès push sur son référentiel pour supprimer les fichiers d'emballage qui ont été déplacés ailleurs. Faites-moi savoir comment vous souhaitez procéder ici.

Merci Gary !

@nunit/framework-team & @CharliePoole - est-ce que quelqu'un n'est pas d'accord pour mettre le compte de @rprouse là-bas, car c'est actuellement lui qui fait les sorties, dans l'idée que nous pourrions passer à quelque chose de plus « basé sur l'organisation » à l'avenir ?

@ChrisMaddock si je pouvais faire une recommandation... Si vous créez un compte nunit et partagez les informations d'identification au sein de l'équipe à l'aide d'un gestionnaire de mots de passe, cela facilite beaucoup la maintenance des packages à l'avenir, plutôt que de les lier à un seul individu. C'est ce que nous faisons avec le package Cake, par exemple :

https://chocolatey.org/packages/cake.portable

Bien que nous, les membres de l'équipe Cake, soyons tous un mainteneur du paquet, c'est le compte principal de cake-build qui pousse toutes les nouvelles versions du paquet. Chocolatey n'a pas le même concept d'organisation que celui récemment publié par NuGet, mais ce que j'ai suggéré ci-dessus convient pour le moment.

Merci Gary - cela semble plus proche de l'endroit où nous voulons être à long terme !

@nunit/framework-team & @CharliePoole - quelqu'un a-t-il des objections à la suggestion de Gary ci-dessus ? Je suis heureux de faire les démarches pour que cela se produise sur celui-ci. ??

@ChrisMaddock n'hésitez pas à me contacter si vous avez besoin de mon aide pour quelque chose.

@ChrisMaddock La création d'un compte nunit à utiliser avec chocolatey pourrait être une bonne voie à suivre. Nous avons obtenu le statut de package de confiance parce que le responsable du package et le détenteur des droits d'auteur étaient la même personne, mais ce n'est pas vraiment évolutif. Une fois qu'il est configuré, nous devrions probablement l'utiliser pour tous nos packages.

Cependant, l'ajout de nunit à ce package particulier n'est pas nécessaire car ce n'est plus un package que nous publions. Nous essayons juste de régler un problème.

@gep13 Ce problème existe depuis longtemps, donc au cas où cela serait déroutant, le résumé est qu'il a commencé comme un problème pour ajouter des emballages chocolatés. Tout ce travail a été fait, principalement par moi. En 2017, j'ai changé le nom de ce problème en la seule chose qui restait à faire, dépréciant le package généré automatiquement existant. Cela aurait probablement été plus clair si je fermais ce problème et en écrivais un nouveau !

TL;DR Le package nunit généré automatiquement ne devrait plus être généré du tout. La combinaison de modules dans ce package n'existe plus et a été remplacée par d'autres noms de package. Le projet NUnit produit déjà des versions chocolatées de ces packages directement.

Je vais continuer la discussion à ce sujet sur dtgm/chocolatey-packages#310

@CharliePoole - merci d'avoir fait l'autre problème.

Concernant les colis que nous souhaitons conserver, souhaitez-vous que je m'occupe de la mise en place d'un compte organisation ? Je pense qu'il aura besoin d'une action de votre part pour l'ajouter en tant que mainteneur, mais je suis heureux de faire un travail de terrain, car vous essayiez de transmettre ce problème !

@ChrisMaddock J'ai créé le problème il y a longtemps, mais je suppose que le projet a un gros retard. Je pense que le travail de cette question se fera réellement là-bas.

Pour l'avenir, je suggère de savoir si l'équipe veut un compte nunit ou préfère suivre qui le fait individuellement. Je suis heureux d'ajouter quiconque devrait être ajouté et de me retirer par la suite, mais je pense que c'est une décision d'équipe ou de chef d'équipe.

WRT les quatre extensions, il n'y a pas d'équipe et pas de lead, c'est pourquoi je n'ai rien fait. Seule l'extension teamcity a un responsable.

FWIW J'ai envisagé de forger certaines extensions à un moment donné et je peux le faire si l'une dont je dépends n'a pas de mainteneur.

Pour l'avenir, je suggère de savoir si l'équipe veut un compte nunit ou préfère suivre qui le fait individuellement. Je suis heureux d'ajouter quiconque devrait être ajouté et de me retirer par la suite, mais je pense que c'est une décision d'équipe ou de chef d'équipe.

D'accord désolé, je m'avance. J'attendrai les réponses de @nunit/framework-team.

Je préférerais que l'organisation compte pour la flexibilité.

@ChrisMaddock Pas de problème. Ma propre préférence (s'il existait) serait un compte d'organisation avec plusieurs identifiants d'utilisateur, comme nous l'avons sur GitHub lui-même. Cela n'étant pas disponible, un identifiant partagé semble être la voie à suivre.

Je suis cool avec un compte d'organisation aussi. @gep13 pouvez-vous [email protected] une fois qu'elles sont configurées ? Ou vous pouvez me DM sur twitter @rprouse.

Je suis d'accord avec le commentaire de @CharliePoole selon simple fait de

@ChrisMaddock avons-nous une liste des packages Chocolatey pour lesquels nous devrions ajouter le compte d'organisation en tant qu'administrateur ? J'ai pris du recul par rapport au maintien de cette partie et je n'ai pas une image complète. J'ai contacté @gep13 avec des informations sur un compte d'organisation à utiliser, nous avons juste besoin des packages auxquels l'appliquer.

J'ai peut-être mal compris mais je pense que l'un de nous vient de créer un compte nunit. Pour comprendre, il ne s'agit que d'un identifiant d'utilisateur et n'est « organisationnel » que dans le sens où nous l'utilisons en tant que tel.

J'ai peut-être mal compris aussi. J'ai envoyé à @gep13 l' une des adresses gmail courantes que nous utilisons pour cela. @gep13 si vous avez besoin de moi pour le configurer et que vous l'ajoutiez en tant que mainteneur, veuillez me contacter.

@ChrisMaddock avons-nous une liste des packages Chocolatey pour lesquels nous devrions ajouter le compte d'organisation en tant qu'administrateur ?

Non, mais je pourrai faire une telle liste la prochaine fois que je serai sur un ordinateur. ??

@rprouse le package dont nous parlons de dépréciation n'est pas celui que nous maintenons. Il a été maintenu par @dtgm qui m'a ajouté et a été créé automatiquement chaque fois qu'un nouveau nunit.msi ou zip apparaissait sur la page de téléchargement. Nous ne produisons plus cet emballage.

La raison de sa dépréciation est que tous les utilisateurs de ce package sauront quoi faire. S'ils l'utilisent encore, ils sont bloqués à 3,4, alors j'espère que ce n'est pas beaucoup.

Lorsque nous sommes passés à ce que j'appelle (je pense que @ferventcoder le fait également) des packages natifs, nous l'avons rendu obsolète mais ne l'avons jamais nettoyé. Le package obsolète ne devrait plus jamais avoir à changer et n'a pas besoin d'avoir nunit ajouté en tant que packager, il n'aura aucun contenu mais dépendra probablement du package de console et aura un long commentaire explicatif que vous voudrez revoir.

L'ID d'organisation nunit doit être ajouté aux packages que nous gérons, pas à celui-ci, car nous ne le téléchargerons pas.

😢 Choco's offline - liste des colis à venir plus tard !

Voici une revue des packages NUnit actuels sur le chocolat que nous devrions viser à ranger. J'ai ajouté ce que je pense être le meilleur plan d'action pour chacun.

Les éléments suivants sont actuellement sous le compte charliepoole. Pour être transféré sur un compte nunit-org :

• NUnit 3 - Extension du chargeur de projet Visual Studio 3.7.0
• NUnit 3 - Extension de chargeur de projet NUnit 3.6.0
• NUnit 3 - Extension de pilote de framework NUnit V2 3.7.0
• NUnit 3 - Extension NUnit V2 Result Writer 3.6.0
  (Supposons pour l'instant que les extensions v2 resteront avec l'organisation, et traiterons tout déplacement éventuel de celles-ci plus tard !)

Les éléments suivants sont sous charliepoole et rprouse, et doivent être transférés vers nunit-org :

• Exécuteur de console NUnit 3 3.8.0

Les packages suivants sont actuellement gérés par dtgm. Les deux premiers sont également maintenus par charliepoole, le troisième ne l'est pas. Les trois devraient être dépréciés au profit de NUnit 3 Console Runner 3.8.0.

• NUnit (Installer) 3.4.0
• NUnité 3.4.0
• Unité N (portable) 3.4.0

Les outils liés à NUnit suivants sont sous charliepoole ou NikolayP, et doivent rester comme tels :

• NUnit 3 GUI Runner 0.6.0
• NUnit 3 - Extension d'écoute d'événement Team City 1.0.4
• Éditeur de projet NUnit 1.0

Le package suivant a été mis en ligne par un utilisateur externe à toutes nos discussions jusqu'à présent. Nous souhaiterons peut-être discuter avec l'utilisateur de la dépréciation en faveur des packages NUnit-organisation en temps voulu - mais c'est un problème distinct !

• Console NUnit (portable) 3.6.1

Ce dernier est une surprise !

Quelques infos sur l'extension TeamCity : j'ai ajouté Nikolay en tant qu'auteur du package pour qu'il puisse faire les mises à jour, mais j'ai gardé mon propre nom dessus. Ce faisant, il conserve un détenteur de droits d'auteur en tant que l'un des auteurs, ce qui a permis à nos emballages d'être traités spécialement par chocolatey. Auparavant, j'avais voulu ajouter Nikolay en tant que détenteur du droit d'auteur, car il a effectué la plupart du travail pendant des années, mais sa société s'y est opposée.

WRT me supprimant ou Rob des packages, nous devons nous assurer que l'utilisation de l'ID d'organisation NUnit continuera à nous donner le traitement spécial que nous avons obtenu pour la révision des packages WRT avant de le faire. La clé semblait avoir au moins un nom en commun en tant qu'auteur du package et propriétaire du logiciel. Cependant, cela fait quelques années que je l'ai mis en place et chocolatey.org a peut-être changé de pratiques depuis lors.

Merci d'avoir compilé la liste @ChrisMaddock , j'apprécie l'aide.

@gep13 J'ai créé un compte pour l'équipe. Le nom d'utilisateur dans nunit.org et l'e-mail sont [email protected]. Pouvez-vous l'ajouter en tant que mainteneur aux packages @ChrisMaddock répertoriés, à l'exception des quatre derniers ? Nous allons essayer de contacter l'auteur du dernier séparément.

De plus, le dernier paragraphe du commentaire de

WRT me supprimant ou Rob des packages, nous devons nous assurer que l'utilisation de l'ID d'organisation NUnit continuera à nous donner le traitement spécial que nous avons obtenu pour la révision des packages WRT avant de le faire. La clé semblait avoir au moins un nom en commun en tant qu'auteur du package et propriétaire du logiciel. Cependant, cela fait quelques années que je l'ai mis en place et chocolatey.org a peut-être changé de pratiques depuis lors.

@rprouse @CharliePoole @ChrisMaddock J'ai ajouté le nouvel utilisateur NUnit Chocolatey à chacun des packages que vous avez demandés. Vous pouvez voir ceci ici :

https://chocolatey.org/profiles/nunit.org

Puis-je vous demander d'ajouter l'adresse e-mail associée à ce compte à un compte gravatar et d'y associer le logo NUnit ? De cette façon, il apparaîtra plus "officiellement" sur chocolatey.org.

En ce qui concerne le _traitement spécial_...

Chacun de ces packages est ce que nous appelons un package de confiance . Cela signifie que chaque nouvelle version de package est toujours soumise aux contrôles de validation et de vérification automatisés. Si une nouvelle version de package échoue à ce stade, elle sera renvoyée à l'état "En attente du responsable de prendre des mesures correctives", ce qui signifie qu'il appartient à l'un de vos collaborateurs de réparer le package et de pousser une version mise à jour. Puisqu'il s'agit d'un package de confiance, il n'aura pas besoin d'attendre qu'un modérateur humain vienne approuver un package, ce qui signifie qu'il est beaucoup plus rapide de passer par le processus de modération.

Donc, pour faire court... Rien n'a changé ici avec l'ajout de ce nouveau mainteneur au paquet. Chacun de ces packages est toujours de confiance.

@rprouse @CharliePoole @ChrisMaddock Je viens de parcourir les packages suivants :

• https://chocolatey.org/packages/nunit
• https://chocolatey.org/packages/nunit.install
• https://chocolatey.org/packages/nunit.portable

À travers le processus de dépréciation :

https://chocolatey.org/docs/how-to-deprecate-a-chocolatey-package

J'ai également supprimé tous les responsables qui figuraient sur ces packages.

S'il vous plaît laissez-moi savoir si vous avez des questions restantes, ou s'il y a autre chose dont vous avez besoin que je réponde.

@gep13 Les

Génial, merci @gep13 ! J'essaierai de jeter un œil à gravatar demain. ??

Alors!

1. J'ai ajouté gravatar et rempli le profil choco de nunit.org (https://chocolatey.org/profiles/nunit.org)
2. @gep13 a pris en charge tous nos besoins en matière de dépréciation et de nouvelle maintenance ! (Merci ! 🎉)
3. J'ai créé un problème pour déprécier le dernier package NUnit non-organisationnel (https://github.com/Roemer/Chocolatey-Packages/issues/7). Je ne suis pas trop inquiet si @Roemer préfère laisser le colis tel quel - mais il semblait logique de proposer de ranger cette partie de l'écosystème pendant que nous sommes ici !

Sur ce, je pense que ce problème peut être clos ! Hourra !

WRT me supprimant ou Rob des packages, nous devons nous assurer que l'utilisation de l'ID d'organisation NUnit continuera à nous donner le traitement spécial que nous avons obtenu pour la révision des packages WRT avant de le faire.

@CharliePoole @rprouse - @gep13 a confirmé que le processus de révision des packages reste inchangé. Je vous laisse prendre la décision de supprimer ou non vos comptes personnels - je n'ai pas ressenti de besoin particulier de le faire de force ! ??

À titre d'exemple, voici ce que nous faisons sur Cake :

https://chocolatey.org/packages/cake.portable

Le compte cake-build est notre compte d'organisation, auquel tout le monde a accès, et c'est ce compte qui fait la poussée réelle des nouveaux packages vers chocolatey.org, cependant, nous ajoutons également tous les comptes personnels des responsables au package en tant que bien. Cela permet aux gens de voir qui ils sont, mais permet également aux gens d'obtenir leurs « points Internet » associés au package sur chocolatey.org, c'est-à-dire le nombre de téléchargements, etc.

Merci @gep13. Je suppose que c'est une question pour nous de réfléchir à la façon dont nous voulons faire cela sur le plan organisationnel. Traditionnellement, tout est publié sous le nom de Charlie Poole. Nous sommes maintenant passés de cela à une organisation plus décentralisée - donc des choses comme celle-ci n'ont pas vraiment été soulevées.

J'ai toujours été un fan de Cake criant à propos de ses contributeurs à chaque occasion (par exemple, les annonces de sortie). Nous devrions en faire plus ! ??