7049 a pris plus d'un mois à déployer même lorsque le PR est fusionné 7 jours après le rapport de bogue

Et l'ouverture d'une demande d'extraction peut toujours entraîner le blocage de la demande dans les limbes jusqu'à ce qu'un responsable de Xamarin prenne le temps de jeter un œil aux fichiers modifiés.

Espérons que l'équipe a un plan pour supprimer certains des goulots d'étranglement autour du processus de publication PR +.

Et l'ouverture d'une demande d'extraction peut toujours entraîner le blocage de la demande dans les limbes jusqu'à ce qu'un responsable de Xamarin prenne le temps de jeter un œil aux fichiers modifiés.

Et regardez cela, après avoir été mentionné dans un problème de haute visibilité, un membre de l'équipe Xamarin.Forms a finalement répondu à https://github.com/xamarin/Xamarin.Forms/pull/7728.

Et l'ouverture d'une demande d'extraction peut toujours entraîner le blocage de la demande dans les limbes jusqu'à ce qu'un responsable de Xamarin prenne le temps de jeter un œil aux fichiers modifiés.

Et regardez cela, après avoir été mentionné dans un problème de haute visibilité, un membre de l'équipe Xamarin.Forms a finalement répondu à xamarin/Xamarin.Forms#7728 .

Je sympathise avec l'équipe. Que de nombreux problèmes ne sont pas faciles à trier/gérer/réparer. Cela étant dit, il faut absolument se concentrer sur l'élimination des goulots d'étranglement et la réduction des problèmes en suspens et des relations publiques.

D'accord, la qualité a toujours été un problème pour tous les aspects du développement de Xamarin. Plusieurs fois, je me sens frustré à cause d'incompatibilités entre les composants, de ne pas fonctionner dans VS ou de planter mon application après une mise à jour vers la nouvelle version de Forms. Les choses devraient juste fonctionner. Je ne devrais pas être obligé de reconstruire ma mise en page pour la 3ème fois car certains contrôles ou mises en page ne fonctionnent tout simplement pas bien ensemble.

Je vois quelques points liés

1) Je ne sais pas combien de personnes travaillent sur Forms, mais il me semble que l'équipe est trop petite pour suivre le rythme de croissance rapide des nouveaux bugs ou des PR. Cela ne fera qu'empirer car ils devront partager leur attention entre Forms et Maui. J'espère vraiment que l'équipe recevra bientôt un coup de pouce substantiel.

2) Cela aiderait vraiment si Microsoft commençait à utiliser Forms sur ses propres applications. Et je ne parle pas de simples applications de démonstration ou de conférence. Je veux dire de vraies applications comme Teams ou Outlook. Je serais heureux si je me trompe sur celui-ci mais je n'ai pas réussi à trouver d'application MS Forms sur les magasins et selon une source comme ce tweet https://twitter.com/safaiyeh/status/1219294459298344961 ils utilisent principalement réagissent originaire de.

• cela n'envoie vraiment pas un bon signal car si MS n'utilise pas sa propre technologie (XF), alors pourquoi devrions-nous le faire ?

• l'utilisation de Forms en interne sur des applications complexes pourrait constituer une couche de test supplémentaire et pourrait réduire le nombre de problèmes rencontrés dans la version publique. De plus, ils ont pu voir que travailler avec Forms n'est pas aussi facile qu'ils nous le disent

3) Je vois un autre problème dans le fait que MS essaie constamment de réinventer la roue sous une forme de XF Xaml au lieu d'utiliser des solutions déjà éprouvées et existantes comme Win UI Xaml. Ils doivent investir du temps dans le développement de fonctionnalités déjà existantes et dans la correction des bogues qui sont introduits à cause de cela, puis il y a moins de temps pour d'autres fonctionnalités et corrections de bogues.

Je suis d'accord à 100% avec @Reveon
oh, et je dois dire que l'utilisation de VisualStudio pour Windows avec Xamarin est une expérience très frustrante.

Ils continuent d'ajouter des bugs exceptionnels, bloquants... je ne sais même pas comment c'est possible (des choses comme casser TOUTES les versions de l'appareil ios, casser les profils d'approvisionnement, casser la reconnaissance de gestes... comment des bogues comme ceux-ci peuvent-ils être mis en production, puis prendre des semaines ou des mois pour être corrigé dans la version de la version ? Je ne sais pas....)

Je suis passé à Rider pour cela et maintenant j'utilise le produit Jetbrains partout :) Au moins, je peux utiliser un IDE qui est exactement le même dans iOS et Windows et continuer à travailler de manière productive.

Je suis sûr qu'avec MAUI, de telles choses vont changer, et tôt ou tard, Microsoft commencera à utiliser MAUI en interne pour des projets sérieux

Autre témoignage :
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

J'ai attendu que mon PR soit fusionné pendant 1,5 mois pour ce problème. Il existe déjà un problème pour Ios et Android a été résolu en juillet 2019 et personne n'a touché pour uwp. J'ai corrigé en avril et demandé à plusieurs reprises une révision et une fusion. C'est vraiment ennuyeux de voir comment les équipes xamarin fonctionnent. Vous pouvez voir qu'ils n'examinent que 1 à 2 PR par jour.
#10316

Bien que je sois souvent frustré, "Xamarin est bogué" est une déclaration dure. Plus de 2000 problèmes ouverts aujourd'hui, si vous vérifiez que Flutter a plus de 5000 problèmes ouverts. Les chiffres ne sont pas si importants. Xamarin.forms offre plus que les autres plates-formes croisées comme uwp (y compris xbox), wpf, mac, gtk, tizen. Il existe donc de nombreux problèmes ouverts pour Wpf par exemple, ce qui est une priorité inférieure pour la plupart d'entre nous.
Le noyau de Xamarin.forms devrait être ios, android et uwp, bien que l'équipe Xamarin néglige souvent uwp.

1. Il devrait y avoir des éléments de base tels que des mises en page, des vues de liste, un carrousel, une vue de collection, des images, des cartes, une étiquette, un éditeur, etc. Ceux-ci devraient être sans bogue. si vous faites une nouvelle version ou une mise à jour sur celles-ci, vous devez vous assurer qu'il n'y a pas de bug majeur. S'il y a un bug, vous devez le résoudre dans un délai d'une semaine max. Mais l'équipe Xamarin publie ce "4.5-4.6" cool avec des fonctionnalités intéressantes (qui a besoin de cet outil sophistiqué 10% de la communauté ?) et le contrôle de l'image est cassé. Le problème a été signalé début mars et n'est toujours pas résolu jusqu'à aujourd'hui. Le même "Bundle into native assemblys" est cassé. Pour ces raisons cruciales, je ne peux pas passer aux versions 4.5 et 4.6. Ils continuent à se développer avec 4.7 en ajoutant de nouvelles fonctionnalités. Moi et la plupart d'entre nous gardons un œil sur les notes de version si nos bugs sont résolus, je ne lis même plus quelle fonctionnalité a été ajoutée.
2. L'équipe Xamarin doit comprendre cela. La principale raison pour laquelle beaucoup de gens choisissent Xamarin est "UWP". Je suis indépendant. Je demande à mon client pourquoi ne pas flotter ou réagir nativement ? Il dit parce que Xamarin a UWP. Je veux UWP aussi. Mais Uwp est principalement bogué avec Xamarin.forms. ils ont introduit CollectionView, c'est vraiment génial mais depuis un an, ce bug n'est pas résolu. Je l'ai corrigé, personne ne révise. J'étais découragé de faire toute autre contribution.
3. Hotreload ne fonctionne pas du tout. J'ai lu sur twitter tous les "kiss kiss" à quel point hotreaload est génial. Je pense qu'il devrait y avoir quelque chose qui ne va pas chez moi ou qu'ils utilisent un autre outil. Parce que souvent hotreload n'est pas mis à jour. J'utilise toujours des outils tiers tels que livexaml, etc. J'ai même créé une simple application console pour effectuer mon propre téléchargement à chaud. ça me coûte 1 jour. Fonctionne bien mieux que celui de Xamarin et fonctionne même pour uwp. Comment peuvent-ils ne pas le livrer ? Ils avaient du livereload qui fonctionnait.

4. Point le plus important ; ce que @Reveon a mentionné. ils ont besoin d'une véritable application d'entreprise qui fonctionne avec xamarin.forms et ils doivent la mettre à jour avec les nouvelles versions pour détecter les vrais problèmes. Ils se plaignent que "ce n'est pas si difficile de donner des repro". Oui, c'est très difficile si ce problème ne se produit que sur votre application d'entreprise, pas sur une application à faire. Vous devez essayer de reproduire la même interface utilisateur. cela peut vous coûter des journées jusqu'à ce que vous compreniez. C'est pourquoi il est très important qu'il y ait quelqu'un ayant une grande application. Je me demande vraiment si l'un de ces développeurs Xamarin que nous voyons sur twitch, youtube, twitter, etc. a-t-il déjà développé une grande application avec xamarin.forms.

5. Je dois admettre quelque chose bien que je n'aime pas utiliser des outils non open source, plus de 50% de mes applications utilisent des outils de synchronisation. Sans Syncfusion, je pense qu'il est si difficile de faire fonctionner une application d'entreprise. Ils ont tout ce que xamarin n'a pas ou ce qu'est le buggy xamarin. Par exemple, j'ai cherché pendant des années un remplacement de sfListView avec un glisser-déposer, une vue par balayage, une disposition linéaire et en grille, une meilleure virtualisation, etc. il buggy. Ne fonctionne pas pour Uwp. de nombreuses fonctionnalités manquantes. Recherchez simplement CollectionView dans les numéros, vous en trouverez des dizaines.

Je crois toujours que Xamarin est le meilleur outil pour les plateformes croisées et j'espère qu'ils considéreront ce problème comme un retour constructif.

Commentaires excellents et constructifs jusqu'à présent. Je lisais la liste et je ressentais la même chose que les autres développeurs. Les problèmes sont courants chez ceux d'entre nous qui utilisent Xamarin.Forms pour développer des applications d'entreprise. Le suivi et la correction des bogues nécessitent plus d'attention, mais surtout, un point qui est clair, et je me suis souvent demandé pourquoi il n'y a pas d'application MS d'entreprise construite avec Xamarin.Forms. MS Teams ou tout autre. Si la réponse est : bien trop compliqué ou impossible à faire avec Xamarin.Forms, il existe un excellent aperçu interne pour améliorer la plate-forme dans son ensemble et essayer de résoudre ces problèmes. Xamarin/MAUI gagnera certainement avec plus de développeurs testant, contribuant et faisant passer le mot, mais cela devrait être une rue à double sens. Encore une fois, je ne me plains pas, mais ce serait énorme de voir, cette année, l'année prochaine, une excellente version MS d'une application mobile construite avec MAUI ou Xamarin. Vérifiez également les frustrations des développeurs ou les améliorations possibles, et portez le développement multiplateforme à un nouveau niveau.

Parce que j'ai été mentionné...

Je dirige un petit projet pour une application multiplateforme entre Android et Windows Desktop (WPF).

Nous avons trouvé beaucoup de bugs, que nous avons dû travailler ou corriger. Actuellement, je démarre un projet interne pour les correctifs et les améliorations de performances, car partager nos solutions est avec cette lente progression impossible. Nous avons aussi des délais.

Apporter des bogues dans le pipeline officiel coûte vraiment bien d'attirer plus d'attention, peut-être que vous obtenez plus de la communauté.

Dans la partie wpf de xamarin, il y a beaucoup de choses à faire. Les performances sont mauvaises et ce sont de simples bugs d'enfer. Mais l'idée derrière et la base sont posées. C'est triste de voir l'état actuel, car cela pourrait être bien mieux...

D'accord, la qualité a toujours été un problème pour tous les aspects du développement de Xamarin. Plusieurs fois, je me sens frustré à cause d'incompatibilités entre les composants, de ne pas fonctionner dans VS ou de planter mon application après une mise à jour vers la nouvelle version de Forms. Les choses devraient juste fonctionner. Je ne devrais pas être obligé de reconstruire ma mise en page pour la 3ème fois car certains contrôles ou mises en page ne fonctionnent tout simplement pas bien ensemble.

Je vois quelques points liés

1. Je ne sais pas combien de personnes travaillent sur Forms, mais pour moi, il semble que l'équipe soit trop petite pour suivre le rythme de croissance rapide des nouveaux bugs ou des PR. Cela ne fera qu'empirer car ils devront partager leur attention entre Forms et Maui. J'espère vraiment que l'équipe recevra bientôt un coup de pouce substantiel.
2. Cela aiderait vraiment si Microsoft commençait à utiliser Forms sur ses propres applications. Et je ne parle pas de simples applications de démonstration ou de conférence. Je veux dire de vraies applications comme Teams ou Outlook. Je serais heureux si je me trompe sur celui-ci mais je n'ai pas réussi à trouver d'application MS Forms sur les magasins et selon une source comme ce tweet https://twitter.com/safaiyeh/status/1219294459298344961 ils utilisent principalement réagissent originaire de.

• cela n'envoie vraiment pas un bon signal car si MS n'utilise pas sa propre technologie (XF), alors pourquoi devrions-nous le faire ?
• l'utilisation de Forms en interne sur des applications complexes pourrait constituer une couche de test supplémentaire et pourrait réduire le nombre de problèmes rencontrés dans la version publique. De plus, ils ont pu voir que travailler avec Forms n'est pas aussi facile qu'ils nous le disent

1. Je vois un autre problème dans le fait que MS essaie constamment de réinventer la roue sous une forme de XF Xaml au lieu d'utiliser des solutions déjà éprouvées et existantes comme Win UI Xaml. Ils doivent investir du temps dans le développement de fonctionnalités déjà existantes et dans la correction des bogues qui sont introduits à cause de cela, puis il y a moins de temps pour d'autres fonctionnalités et corrections de bogues.

Je suis d'accord avec bon nombre des problèmes que vous avez mentionnés. Microsoft doit absolument créer une application d'entreprise à l'aide de Xamarin Forms ou d'iOS ou d'Android. Une fois qu'ils ont un exemple d'application d'entreprise fonctionnel, nous ne pouvons pas nous plaindre que la création d'applications professionnelles soit frustrante.

Xamarin Forms est un excellent framework multiplateforme pour ceux qui souhaitent créer une application une fois et travailler partout. Cela fonctionne très bien si vous créez des applications simples. Mais une fois que vous commencez à créer une application plus professionnelle avec plus de fonctionnalités telles que des animations, des onglets segmentés, la virtualisation des données, des mises en page complexes, etc., vous vous retrouvez de plus en plus à lutter contre le framework pour faire fonctionner une fonctionnalité. Je trouve que les choses simples qui devraient fonctionner ne sont pas évidentes ou nécessitent des hacks pour que cela fonctionne.

Des fonctionnalités telles que Xamarin Hot Reload sont encore prématurées dans leur stade de développement. Par exemple, si je modifie un style dans App.xaml ou dans un dictionnaire de ressources référencé depuis App.xaml, où je stocke mes styles et ressources, Hot Reload va gâcher la mise en page de l'application dans le simulateur ou provoquer le application à planter.

Je trouve que Visual Studio est incroyablement bogué lors du développement d'applications Xamarin. Par exemple, si mon projet Android est sélectionné comme projet de démarrage, testez-le, puis passez à mon projet iOS en tant que projet de démarrage, il affichera toutes sortes de fausses erreurs. Détruire les dossiers bin ou obj n'aide pas. Il me faut redémarrer VS. Dans un autre exemple, VS perdra aléatoirement sa connexion à mon Mac pendant que je débogue mon application. Cela fera geler mon VS. Je vais faire une crise de colère, remettre en question mon passe-temps et ma vie de développeur mobile, et forcer à tuer VS à l'aide du Gestionnaire des tâches. De plus, je trouve que les futures versions de Visual Studio réintroduisent des bogues qui ont été corrigés dans les versions précédentes. Je ne connais aucun moyen d'installer une version antérieure de VS après la publication de la dernière version et je l'installe. Je peux le désinstaller et essayer de le réinstaller à l'aide du programme d'installation, mais il installera toujours la dernière version. Ce n'est pas comme un package NuGet où vous pouvez installer n'importe quelle version.

Enfin, pourquoi un contrôle d'onglet segmenté ne fait-il pas déjà partie de la boîte à outils Xamarin ? Les onglets segmentés sont utilisés presque partout. Je ne devrais pas avoir à utiliser la boîte à outils Syncfusion ou une autre boîte à outils pour utiliser un contrôle si courant.

Je suis nerveux à l'idée d'adopter MAUI lorsqu'il sort dans n'importe quelle application professionnelle que je développe jusqu'à ce que bon nombre de ces frustrations des développeurs utilisant Xamarin et Visual Studio soient résolues. Je vais jouer et expérimenter avec quand il sortira. Mais j'aurai plus de confiance si Microsoft sort et crée une application d'entreprise en utilisant MAUI au lieu de créer de simples applications de démonstration.

Quelqu'un peut-il nous éclairer sur les feuilles de route Xamarin Forms et MAUI ? Seront-ils maintenus en parallèle ? Y a-t-il un arrêt dur pour la prise en charge de Xamarin Forms et Microsoft nous poussera-t-il MAUI dans la gorge dans une future mise à jour de Visual Studio ?

Merci

@SunnyMukherjee De la FAQ,

Quel est l'avenir de Xamarin.Forms ?

La prochaine version majeure de Xamarin.Forms sera disponible vers septembre 2020 et continuera d'être mise à jour jusqu'à la sortie de .NET MAUI avec .NET 6. Après cela, Xamarin.Forms continuera à recevoir un service prioritaire pendant 12 mois.

Fondamentalement, Xamarin.Forms sera tué après la version 5.

@SunnyMukherjee De la FAQ,

Quel est l'avenir de Xamarin.Forms ?

La prochaine version majeure de Xamarin.Forms sera disponible vers septembre 2020 et continuera d'être mise à jour jusqu'à la sortie de .NET MAUI avec .NET 6. Après cela, Xamarin.Forms continuera à recevoir un service prioritaire pendant 12 mois.

Fondamentalement, Xamarin.Forms sera tué après la version 5.

D'ici la mi-2021. . . si Covid ne me tue pas avant, Maui ou Xamarin Forms feront le travail.

@SunnyMukherjee J'entends ta douleur. J'utilise Xamarin.Forms depuis sa sortie, et il a fait du chemin depuis. N'oubliez pas que Microsoft n'a pas créé Xamarin.Forms, ils n'ont acheté Xamarin qu'en 2018. MAUI est donc le projet de Microsoft de le réécrire pour qu'il soit meilleur et qu'il fonctionne de manière transparente avec l'ensemble du .net. Travailler avec Xamarin.Forms n'est pas trivial car ce qu'il doit faire n'est pas trivial. Beaucoup de gens disent qu'ils devraient simplement faire ce qu'Uno ou Flutter ont fait et effectuer les contrôles eux-mêmes complètement - mais c'est contre ce qu'est Xamarin.Forms. C'est un framework de développement natif - exposant les contrôles natifs d'une manière commune. Ce n'est pas une mince tâche. J'ai également eu beaucoup de problèmes avec Xamarin.Forms, mais dans l'ensemble, le temps gagné en l'utilisant au lieu d'écrire la même application dans plusieurs langues l'emporte de loin sur les problèmes. De plus, le fait de pouvoir partager 90% du code avec les projets principaux ASP.Net le rend encore plus intéressant.
Bien qu'il soit important de faire savoir à Microsoft ce que nous voulons dans MAUI - mais nous devons comprendre que ce n'est pas une mince tâche pour eux, et j'espère que MAUI sera un grand pas dans la bonne direction.
Regardez cette vidéo de la version récente de la démonstration de MAUI et expliquez comment elle s'intègre dans les feuilles de route, ainsi que ce qu'elles feront et prendront en charge sur Xamarin.Forms en attendant :
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

En lisant ici, je me demande ce que je peux apprendre ici pour améliorer la qualité de Xamarin.Forms. J'adorerais revenir à la question initiale de

Des idées sur la façon de s'améliorer?

L'un de nos principaux objectifs d'ici la livraison de .NET MAUI est d'améliorer les bases, le point de départ. Pour cette raison, nous consacrons une grande partie de nos sprints actuels aux problèmes de CollectionView, et nous proposons de suspendre le développement de fonctionnalités dans Xamarin.Forms 5 afin que nous ayons de septembre 2020 à novembre 2021 pour nous concentrer davantage sur la résolution des problèmes.

Tout cela est visible sur nos tableaux de projets de sprint.

En bref:

• Soyez plus rapide sur la demande d'extraction de la communauté.

J'ai rebasé l'arborescence des demandes de tirage il y a quelques jours. Pourquoi l'examen est-il si long ?

WPF-Renderer, points de bugs potentiels :

• Mesurer/Arranger les contrôles
• Logical/Visual-Childtree est cassé
• Performance

Salut @davidortinau , je pense qu'un bon moyen de résoudre ce

• tri des problèmes de bogue
• gérer, envoyer et pousser pour l'examen et la fusion des relations publiques.

Il/elle sera notre point de contact si quelque chose va trop lentement et il/elle pourra expliquer ce qui se passe.
De plus, s'il y a des obstacles non légaux, ce sera fantastique si nous pouvons avoir une chaîne Twitch où à son tour quelqu'un corrige un bogue ou examine un RP en ligne. IHMO, cela pourrait avoir un impact énorme sur l'intérêt et la collaboration des développeurs externes.
Ceci est valable à la fois pour .NET MAUI et Xamarin Forms. Mais peut-être que je ne suis qu'un rêveur

Je ne suis pas vraiment surpris que Xamarin.Forms ait beaucoup de bogues compte tenu du nombre de plates-formes sur lesquelles il s'exécute et des modifications apportées par les plates-formes ou par son propre développement.

Ce qui me surprend cependant, c'est le nombre de bugs de régression, des choses qui fonctionnaient avant ou qui avaient été corrigées avant et qui cassaient ensuite avec la prochaine version.
Pour moi, c'est un signe clair de ne pas tester assez. Un régime de test plus strict peut conduire à ce que certains changements ne soient pas dans la prochaine version, mais les détecter tôt est vraiment nécessaire pour éviter la stigmatisation d'un produit qui n'est pas fiable, pour le dire sans ambages.

Plus de tests sont quelque chose que j'aimerais voir comme leçon tirée de Xamarin.Forms pour MAUI. Cela pourrait éviter de nombreux problèmes signalés et des ressources gaspillées, car le code bogué prenait un long chemin au lieu d'être immédiatement résolu avec le PR créé.

Quand j'ai dit "fonctionnalités de base" et "bugs critiques". C'est ce que je veux dire, un problème comme celui-ci . C'est super embêtant maintenant. J'ai fait une sortie par semaine sans vraiment connaître ce problème. Je me demandais pourquoi la rétention des applications avait considérablement chuté. Imaginez que j'ai principalement des non-anglophones et qu'un utilisateur espagnol ou allemand ouvre l'application et qu'elle est en anglais à cause de ce bogue. Il le désinstallera immédiatement bien que mon application soit traduite dans ces langues. Ce bug peut arriver mais il a été signalé il y a une monture ? pourquoi n'a pas été corrigé. Même Appcenter et Azure Pipelines ont ce bogue.

Pour améliorer le cadre. Je voudrais ajouter:

Améliorez la possibilité d'écrire votre propre moteur de rendu. Évitez le mot-clé internal .

Plutôt que de simplement publier des exemples de projets sur GitHub, Microsoft peut créer une application d'entreprise professionnelle comme OneDrive ou l'application Xbox avec Xamarin Forms, iOS ou Android et la publier sur l'App Store afin que des personnes autres que des développeurs l'utilisent. Microsoft l'a déjà fait en migrant Visual Studio de C++ vers C# et WPF (si le client est le développeur dans ce cas). Cela informera Microsoft de nos points faibles et s'ils réussissent, cela donnera une confiance énorme à la communauté des développeurs que tout est possible avec Xamarin.

Je suis content qu'il y ait une publication à ce sujet et je voudrais peser ma frustration. Je suis souvent passif en postant des réponses à des problèmes existants, mais ce qui me déclenche, c'est ce problème par rapport aux BundleAssemblies ; après plus de 2 mois de ce problème à fort impact, je n'ai toujours aucune indication claire de la solution, de l'état ou de la voie à suivre par les membres Xamarin.

Je dirige une équipe Agile Scrum, et très souvent le KPI est la Vélocité (la quantité de travail effectué). Parfois, lorsque le problème atteint un certain niveau, ma déclaration finale sera toujours "... Je me demande ce que je peux apprendre ici pour améliorer la qualité de " [notre produit]. Aucune offense (vraiment), mais c'est juste pour fréquenter mon patron ou notre client. Quand je dis cela dans ce genre de contexte de discussion, cela signifiera seulement que moi ou mon Product Owner ne sommes pas à la hauteur ou que nous sommes dans un état de déni ou pire encore, nous ne savons vraiment pas ce qui se passe. (Félicitations à l'une de nos parties prenantes qui me gifle)

Ce qui me dérange vraiment, ce sont les bugs de régression et le manque de réponse/explication concise au problème. Chaque version de XF est susceptible de casser quelque chose ; et cela casse quelque chose qui est évident - alignement incorrect, image ne s'affichant pas, troncature du texte ne fonctionnant pas, etc. La moitié de nos cas de test sont juste pour vérifier ces régressions XF ; c'est ridicule. De toute évidence, il y a quelque chose qui ne va pas avec les tests internes de XF. Même lorsqu'un bogue de show-stopper est reconnu, il peut toujours y avoir plusieurs nouvelles versions ultérieures ; quel est l'intérêt de ces nouvelles versions quand on ne peut pas l'utiliser ? Ces nouvelles versions ne devraient-elles pas être intégrées à votre bêta ?

Cela dit, moi et nos parties prenantes sommes très fatigués de la "culture toxique" avec XF. C'est comme la façon dont Windows 10 peut publier une mise à jour qui supprime les fichiers de l'utilisateur ou le système de l'utilisateur en brique (mais au moins leur réponse et leur correctif sont rapides). Je crois que notre frustration ici ne concerne pas le manque de fonctionnalités dans XF, mais la qualité de la version. Comment XF peut-il améliorer la qualité ? Vous pouvez effectuer une recherche en ligne et obtenir des millions de résultats ; et je ne sais même pas par où commencer ici sans être arrogant pour saper la compréhension de Microsoft de "l'assurance qualité". Je suis sûr que Microsoft sait comment faire de l'assurance qualité (hé, j'ai lu les livres blancs de Microsoft à ce sujet). Cela se résume à la personne en charge; il/elle a besoin de la responsabilité, de la reddition de comptes et de l'engagement pour améliorer (ou mettre en œuvre) le contrôle de la qualité.

Je pense que la chose la plus frustrante concernant XF est lorsque notre contribution (qu'il s'agisse d'un nouveau PR, d'un nouveau problème, ou même d'une simple question ou d'un retour) est simplement ignorée par l'équipe.
L'équipe est probablement trop petite. Mais avoir une personne dédiée à fournir des réponses dans un délai raisonnable aiderait certainement.

Un bon exemple est cette régression concernant les BundleAssemblies (elle a déjà été mentionnée plusieurs fois).
Un autre bon exemple est ce problème concernant CollectionView.

Une autre préoccupation pour moi est qu'une application XF est impactée par des changements dans XF bien sûr, mais aussi Mono, Visual Studio, Xamarin Framework, DotNet, et même certaines bibliothèques Microsoft.
J'ai le sentiment que ces équipes ne communiquent pas bien en interne.
À mon avis, le fait que Microsoft utilise XF en interne pour ses applications aiderait certainement.

Encore une fois, un bon exemple est cette régression , dont la cause première se trouve en fait dans Mono et AndroidX.
Mais je peux aussi mentionner ce problème dans les extensions dotnet impactant les applications iOS, ou encore ce problème dans msal.
Et bien sûr ce problème dans Visual Studio , concernant le lien source.

Les gens ici ont fait un excellent travail en disant la plupart de ce que j'allais dire en détail, alors je vais faire vite

Problèmes techniques

• Visual Studio plante plus de 3 fois/minute lorsque vous travaillez avec XF.
• Beaucoup de contrôles de base manquent, ou nécessitent un diable pour les façonner comme ils sont censés être.
• Lorsque vous dites XF, vous dites simplement le pire framework multiplateforme de performances, et permettez-moi d'être clair pour les personnes qui disent que XF s'attaque à android/ios natif ... et c'est dur. Il suffit de regarder! regarde s'il te plait! pour l'amour de Dieu! chez flutter, RN, NativeScript... Ils ont tous le même objectif mais XF est loin derrière
• Le rechargement à chaud ne fonctionne bien que lorsque vous créez un nouveau projet et que vous créez le texte par défaut dans le côté gauche et c'est tout, alors vous êtes seul !
• Tout le monde dans la communauté flutter par exemple dans chaque version est comme : Oh OMG c'est tellement cool ce qu'ils ont fait, d'un autre côté la com XF est comme : Voyons ce qu'ils ont cassé ou ce qu'ils ont ajouté dont seulement 10% de la com a besoin !
• Un voyage de départ en utilisant XF est une série de diables, un exemple serait : récemment, j'ai dû créer l'un des contrôles communs dans toutes les applications sur Playstore qui est une simple icône d'onglet inférieur uniquement, l'utilisation d'un shell avec une icône n'a qu'une grande marge en bas qui a l'air moche et comme tout le monde, j'ai créé un problème, seulement pour remarquer qu'un problème similaire a été résolu il y a plus de 6 mois... Et aucune solution à ce problème
• Pensez à une application okey ? Une application ? A-t-il un achat intégré ou une sorte de service premium ? Bien sûr que oui. Alors vous commencez à chercher un plugin pour google pay et apple pay non ? Ou même paypale non ? Laissez-moi vous dire quelque chose, il n'y en a pas !!! Quand vous demandez à l'équipe officielle de XF, vous savez ce qu'ils vont répondre ? Ils vous envoient un lien vers un plugin obsolète non officiel créé par un homme (que je respecte) il y a 2 ans sans mise à jour, WTF (désolé) !!

Pas technique

• Oh comme ooon même la documentation officielle est très pauvre, ils abordent des fonctionnalités au niveau de l'application à faire et des tutoriels pratiques
• Je détestais XF avant même de l'utiliser, tu sais pourquoi ? Tout le monde dit que même MS ne l'utilise pas, alors pourquoi le F l'utiliseriez-vous ?
• Une réponse très lente pour les problèmes et les relations publiques que la communauté fait sur son propre temps et ses propres dépenses pour aider l'équipe XF !!!

Solutions

• L'équipe XF est très très petite, comment une entreprise aussi grande que Microsoft peut-elle ne pas embaucher suffisamment de personnes pour améliorer son propre produit ? Il y a des talents partout dans le monde qui aiment Microsoft autant que moi !
• Le XF devrait s'attaquer aux problèmes de haut niveau avant de sortir, cela montre seulement à quel point l'équipe est immature, comme juste un navire qui s'en soucie ...
• Microsoft le plus et est obligé d'utiliser XF pour ses produits ! Sinon c'est juste une façon de dire que XF est bon mais non je n'aime pas ça yukh
• Faites une documentation très riche ! Un doc qui est le premier à consulter dans la plupart des situations, embauchez plus de personnes ! c'est aussi simple que cela, il y a beaucoup de développeurs expérimentés avec qui vous pouvez travailler avec des blogs
• XF n'est pas aussi connu que Flutter, faites des partenariats avec les grands influenceurs du codage sur youtube, même une simple mention aide XF
• C'est bien aussi de regarder d'autres produits et de voir ce que les développeurs aiment à leur sujet et de créer votre propre version. Flutter par exemple.
• N'ayez pas peur de demander à la communauté ce qu'elle veut, ne vivez pas sous un rocher et faites ce que personne n'utilisera !

Je suis vraiment désolé pour mon comportement agressif et mon mauvais anglais, j'aime vraiment beaucoup XF !
Maui est un nouveau point de départ, s'il vous plaît, faites-en la nouvelle révolution, tout le monde s'attend à quelque chose de grand, alors ne nous décevez pas, nous avons de grands espoirs.

@Amine-Smahi Veuillez contacter par e-mail avec plus d'informations sur le comportement qui conduit aux plantages ([email protected]).

Je suis tout à fait d'accord pour dire que la correction des bogues et le processus de test des nouvelles fonctionnalités sont horribles.

Par exemple:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - arrête d'utiliser ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - arrête d'utiliser CompressedLayout

Lorsque vous ajoutez de nouvelles fonctionnalités qui améliorent les performances, c'est génial ! Mais lorsque ces fonctionnalités sont inutilisables, c'est très décevant.

Et certains des problèmes qui affectent mes applications et qui ne sont pas résolus depuis longtemps :
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

L'équipe doit assumer la responsabilité des fonctionnalités qu'elle implémente. Par exemple, @StephaneDelcroix a implémenté https://github.com/xamarin/Xamarin.Forms/pull/1136. Je pense qu'il est la personne qui devrait être affectée à https://github.com/xamarin/Xamarin.Forms/issues/4168 et corriger les bogues liés à CompressedLayout.

A propos de la documentation : je pense personnellement que ça va plutôt bien, sauf pour les notes de version, qui sont totalement f * d up ;) (toujours en retard ou incomplètes)
Encore une fois, je ne parle pas spécifiquement de XF, mais plus généralement de l'ensemble du framework xamarin (xamarin.android, xamarin.ios, visual studio, mono, composants...).

Voici un exemple : notes de version de xamarin ios

@melimion

Lorsque vous ajoutez de nouvelles fonctionnalités qui améliorent les performances, c'est génial ! Mais lorsque ces fonctionnalités sont inutilisables, c'est très décevant.

C'est absolument vrai.
Vous avez ajouté un CollectionView. Le résultat est un tas d'erreurs sur Android, sur iOS c'est généralement inutilisable (Exception Disposed, NSinconsistency exception, etc. Et c'est si vous faites tout selon les guides officiels (!).
Vous avez ajouté CarouselView-les erreurs sont les mêmes.
Nous devons utiliser un Listview obsolète mais plus stable.

Maintenant, quand je vois le titre "nous avons ajouté", je fais immédiatement défiler plus loin.
Et vous avez aussi d'autres éléments, par exemple
Swipeview, Expander, qui ont aussi beaucoup d'erreurs.
Et puis il y a, comme l'a écrit la personne ci-dessus, un studio visuel mono avec ses propres bugs.

Annulez les nouvelles fonctionnalités dans 4.7-4.8, faites attention aux corrections de bogues.
Le développement sur Xamarin, c'est comme trouver des solutions de contournement, des solutions temporaires.
Je m'excuse pour mon mauvais anglais

Hier j'ai vérifié. Il y a plus de 200 problèmes à fort impact. Il ne sert à rien de publier de nouvelles fonctionnalités, lorsque les bogues critiques doivent encore être résolus. Je suis d'accord avec la proposition précédente. Arrêtez les nouvelles fonctionnalités. Prenez le temps de résoudre et de réduire le nombre de problèmes. Je suis bloqué à 4.4, par exemple, à cause d'un problème. Imaginez tellement plus de gens dans cette situation. La stabilité et les performances passent en premier, s'il n'y a pas de main-d'œuvre pour avoir l'innovation et la maintenance à mon humble avis.

Je me demande s'il pourrait y avoir une sorte de sondage parmi les développeurs XF pour voir si nous préférons voir des efforts d'ingénierie pour éliminer les bogues existants ou ajouter les fonctionnalités prévues pour la 4.7 et au-delà. Je veux dire que les nouvelles fonctionnalités ajouteront elles-mêmes plus de nouveaux bugs provoquant plus de remaniement et plus de retard... parfois, un bon gel des fonctionnalités à l'ancienne est nécessaire.

Pour moi personnellement, je voudrais voir le plus d'efforts aller à MAUI, ce qui ressemble à une réinitialisation sensée de l'architecture XF, avec le deuxième plus d'efforts pour éliminer les bogues à fort impact. L'ajout de nouvelles fonctionnalités ne figurerait même pas sur ma liste - je préférerais les ajouter lorsque nous aurons une meilleure plate-forme pour les ajouter.

@freever je suis tout à fait d'accord !
Non seulement cela rendra les développeurs Xamarin actuels plus heureux, mais cela résoudra également ces bogues pour MAUI !

Je ne sais pas si ces bogues seront effectués pour être corrigés ici dans MAUI, ou seront-ils corrigés dans Xamarin.Forms.

J'ai l'impression que @davidortinau a couvert l'esprit de ce numéro ici

https://github.com/dotnet/maui/issues/109#issuecomment-635078640

J'ai mis à jour la description avec son commentaire

Je veux vraiment souligner cette partie de ce qu'il a dit à nouveau pour tout le monde

nous consacrons une grande partie de nos sprints actuels aux problèmes de CollectionView, et nous proposons de suspendre le développement de fonctionnalités dans Xamarin.Forms 5 afin que nous ayons de septembre 2020 à novembre 2021 pour nous concentrer davantage sur la résolution des problèmes.

PureWeen a fermé cela il y a 10 heures

Des dizaines de développeurs xamarin ont exprimé leur avis dans ce ticket, et je n'ai pas l'impression qu'ils ont été entendus.
Malheureusement, vous venez de prouver mon point

@PureWeen Ce problème couvre bien plus qu'un simple nombre de bogues. Ils sont même répertoriés sous forme de points.

@tranb3r

Je pense que la chose la plus frustrante concernant XF est lorsque notre contribution (qu'il s'agisse d'un nouveau PR, d'un nouveau problème, ou même d'une simple question ou d'un retour) est simplement ignorée par l'équipe.

En quoi le commentaire de @davidortinau vous manque-t-il ? Le point principal que je veux dire est que nous ralentissons le développement de nouvelles fonctionnalités afin que nous puissions nous concentrer davantage sur les relations publiques ouvertes et les bogues, puis finalement arriver à .net maui qui sera notre nouveau produit basé sur .net 6

@Happypig375

@pauldipietro a contacté la personne qui a publié ce problème afin qu'il puisse commencer à traiter ces problèmes plus directement avec elle.

L'esprit de ce numéro est que XF a trop de bugs et ignore la communauté. Nous ralentissons donc les nouveaux développements pour nous concentrer davantage sur les bogues existants et les PR ouverts

S'il y a d'autres problèmes en dehors des bogues ouverts, ouvrons les problèmes pour ceux-ci. Mais ce problème concerne le nombre de bogues ouverts et nous avons un plan pour y remédier.

Avec MAUI, nous devrions avoir un processus de correction de bogues aussi rapide que possible. Des idées sur la façon de s'améliorer?

Nous supprimons un tas d'aspects hérités de Form avec .NET Maui et nous passons cette année avant de nous concentrer fortement sur les bogues et les PR ouverts afin que nous puissions être plus productifs avec .NET Maui

Ceci est notre panneau de projet

https://github.com/xamarin/Xamarin.Forms/projects

Vous pouvez voir ce que nous ajoutons à chaque sprint
https://github.com/xamarin/Xamarin.Forms/projects/70

Voici notre feuille de route
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
Nous essayons d'être aussi transparents que possible avec ce sur quoi nous travaillons

Si les problèmes sur ces dépôts sont ping ou ont une concentration élevée, nous essayons de les faire remonter, mais parfois ces algorithmes ne sont pas parfaits.

@Amine-Smahi voici le tableau du projet pour le shell et ce que nous considérons comme des bloqueurs
https://github.com/xamarin/Xamarin.Forms/projects/54

Pouvez-vous m'indiquer le problème auquel vous faites référence afin que je puisse y jeter un coup d'œil?

@PureWeen

En quoi le commentaire de @davidortinau vous manque-t-il ? Le point principal que je veux dire est que nous ralentissons le développement de nouvelles fonctionnalités afin que nous puissions nous concentrer davantage sur les relations publiques ouvertes et les bogues, puis finalement arriver à .net maui qui sera notre nouveau produit basé sur .net 6

Comme mentionné précédemment, ce problème couvre bien plus que le nombre de bogues dans XF.

S'il y a d'autres problèmes en dehors des bogues ouverts, ouvrons les problèmes pour ceux-ci. Mais ce problème concerne le nombre de bogues ouverts et nous avons un plan pour y remédier.

Il y a déjà trop de sujets ouverts !!! Quel est l'intérêt d'en ouvrir de nouveaux si vous les ignorez simplement...

Par exemple, l'un des points importants mentionnés précédemment est que les équipes Microsoft doivent utiliser xamarin lors du développement d'applications.
Entendez-vous ce retour ? Que devons-nous faire pour vous convaincre que c'est une bonne idée ? Sommes-nous censés ouvrir un sujet pour cela ???

Comme mentionné précédemment, ce problème couvre bien plus que le nombre de bogues dans XF.

Créons des problèmes différents pour ceux-ci. Aborder plusieurs choses en un seul problème ne sera pas productif.

Sur quels autres commentaires ici qui n'ont rien à voir avec des problèmes de bogues ouverts/prs/fragilité autour de XF voulez-vous des éclaircissements ?

Par exemple, l'un des points importants mentionnés précédemment est que les équipes Microsoft doivent utiliser xamarin lors du développement d'applications.
Entendez-vous ce retour ? Que devons-nous faire pour vous convaincre que c'est une bonne idée ? Sommes-nous censés ouvrir un sujet pour cela ???

Oui, nous essayons de convaincre littéralement tout le monde d'utiliser Xamarin

Nous discutons beaucoup avec les équipes internes des choix d'applications et c'est une discussion permanente. Beaucoup de ces discussions internes guideront également la direction de .NET Maui.

Je ne suis pas sûr de ce que je peux commenter d'autre à ce sujet. Il n'y a pas grand-chose d'actionnable ici que je puisse faire pour vous aider spécifiquement en tant qu'utilisateur.

@PureWeen L'esprit de ce numéro est que XF a trop de bugs et ignore la communauté. Nous ralentissons donc les nouveaux développements pour nous concentrer davantage sur les bogues existants et les PR ouverts

Nous nous attendons donc à un taux de corrections de bogues légèrement plus rapide pendant un certain temps. C'est bien mais ne résout pas complètement ce problème. Faire passer XF de la qualité bêta à la version stable est une tâche très importante et aucune solution rapide ou stratégie unique n'y parviendra. Il faudra des changements organisationnels, philosophiques et architecturaux majeurs. Je voudrais suggerer:

1. Simplifier le référentiel pour faciliter la contribution et la révision des contributions. La nouvelle architecture de rendu peut être utile si elle déplace XAML du noyau et offre une approche plus sûre du type aux rendus.
2. Priorisez les corrections de bogues et nettoyez le code par rapport aux fonctionnalités. Étant donné que la culture de Xamarin consiste à ajouter de nouvelles fonctionnalités tout en ignorant les bogues, le meilleur moyen est d'interdire complètement les nouvelles fonctionnalités jusqu'à ce qu'un seuil de qualité soit atteint pour les fonctionnalités existantes.
3. Autoriser les changements de rupture qui corrigent les bogues et nettoient le code.
4. Utilisez pleinement .Net pour réduire les bogues. Gardez les choses à l'intérieur du système de types dans la mesure du possible et adoptez les NRT C# 8.
5. Corrigez d'abord les contrôles les plus élémentaires , puis les contrôles restants.
6. Jetez les anciens systèmes d'exploitation cibles et les anciens éditeurs pour nettoyer le référentiel, rationaliser les tests et libérer des ressources pour les corrections de bogues.
7. Signaler une métrique de bugs publiquement. Cela aidera à concentrer l'organisation sur les bogues. Mettez la progression des bogues dans la première section de tout blog concernant une mise à jour.
8. Supprimez des fonctionnalités pour réduire la taille du référentiel, pour le rendre plus facile à gérer.

Notre expérience : nous n'utilisons que des vues XF de base car nous ne faisons confiance à rien d'autre pour être utilisable. Étiquette, Entrée, Bouton, Sélecteur, Commutateur, DatePicker, Curseur, StackLayout, ScrollView, ContentView, Grid, ContentPage. Mais même alors, les insectes surgissent et restent pendant des mois. Il est si difficile d'obtenir des correctifs dans XF que nous nous contentons de copier et coller des moteurs de rendu dans notre code.

Simplifier le référentiel pour faciliter la contribution et la révision des contributions. La nouvelle architecture de rendu peut être utile si elle déplace XAML du noyau et offre une approche plus sûre du type aux rendus.

C'est notre plan. J'ai créé un problème d'espace réservé ici que vous pouvez suivre ou proposer vos suggestions https://github.com/dotnet/maui/issues/147

Priorisez les corrections de bogues et nettoyez le code par rapport aux fonctionnalités. Étant donné que la culture de Xamarin consiste à ajouter de nouvelles fonctionnalités tout en ignorant les bogues, le meilleur moyen est d'interdire complètement les nouvelles fonctionnalités jusqu'à ce qu'un seuil de qualité soit atteint pour les fonctionnalités existantes.

C'est surtout notre plan.

Autoriser les changements de rupture qui corrigent les bogues et nettoient le code.
Utilisez pleinement .Net pour réduire les bogues. Gardez les choses à l'intérieur du système de types dans la mesure du possible et adoptez les NRT C# 8.

C'est lentement notre plan. Mais il est important de comprendre l'ensemble des utilisateurs qui utilisent nos produits. Par exemple, une fois que nous avons rompu le support vs2017, ce problème est apparu ici et a reçu une tonne de commentaires d'utilisateurs.
https://github.com/xamarin/Xamarin.Forms/issues/7602

Nous ne pouvons donc pas nous contenter de sauter le pas. J'aimerais à 100% faire ce saut, mais nous ne pouvons pas simplement briser les gens.

Mais nous prenons constamment des mesures pour nous préparer à ce saut. Par exemple le PR ici
https://github.com/xamarin/Xamarin.Forms/pull/10937

Cela me permettra d'exécuter un processus CI interne pour tester par rapport à C# 8 et à d'autres fonctionnalités bêta afin qu'une fois que nous puissions franchir le pas, ce sera un pas facile à franchir.

Corrigez d'abord les contrôles les plus élémentaires, puis les contrôles restants.
Jetez les anciens systèmes d'exploitation cibles et les anciens éditeurs pour nettoyer le référentiel, rationaliser les tests et libérer des ressources pour les corrections de bogues.

C'est notre plan comme je l'ai mentionné ci-dessus

Signaler une métrique de bugs publiquement. Cela aidera à concentrer l'organisation sur les bogues. Mettez la progression des bogues dans la première section de tout blog concernant une mise à jour.

En regardant cela. @samhouts exécute beaucoup de ces rapports pour nous à chaque sprint afin que nous ayons une perspective sur tout, mais nous examinerons cela mieux à la communauté.

Supprimez des fonctionnalités pour réduire la taille du référentiel, pour le rendre plus maintenable.

C'est notre plan avec .net MAUI. Avant de lancer notre plan .NET MAUI, nous avons préparé des listes de domaines que nous pouvons réduire afin d'être plus efficaces. Une grande partie de cela sera le travail de rendu.

Bonjour, en plus des problèmes mentionnés, il existe de nombreux bogues liés aux langues de droite à gauche. Langues correctes), mais le manque de prise en charge complète des cultures de droite à gauche est décourageant et décevant et empêche en fait les développeurs d'utiliser XF dans les applications internationales / multilingues / de droite à gauche.
Merci.

Prochain numéro de deux mois : https://github.com/xamarin/Xamarin.Forms/issues/11166
Bug créé le 22 juin.
PR ouvert le 25 juin.
Statut du bogue 17 août : Toujours pas fusionné. Pourquoi? ;(

@PawKanarek bienvenue sur Xamarin. généralement, ils ne fusionnent que les correctifs ou les Prs effectués par l'équipe. c'est pourquoi il est décourageant de contribuer sur Xamarin. Je pense qu'ils ont réduit la capacité de l'équipe. seulement 2-3 personnes travaillant activement sur le projet. si vous avez besoin d'une solution rapide, créez vos propres packages xamarin nuget.

@EmilAlipiev Mais cette fois le PR (pour #11166) a été ouvert par un membre de l'équipe Xamarin et n'a toujours pas été fusionné xD

Si vous jetez un œil à nos notes de version et à nos informations GitHub, nous fusionnons des tonnes de relations publiques de la communauté. En fait, je vois ton nom sur la dernière liste , @EmilAlipiev :)

Vous pouvez voir qu'au cours du mois dernier, 40 nouvelles demandes de tirage ont été ouvertes par 18 personnes différentes . Les demandes de tirage doivent être entièrement testées et examinées, et avec la quantité que nous recevons, nous devons hiérarchiser les problèmes de blocage et les régressions majeures sans solution de contournement.

Je sais que nous ne sommes pas toujours parfaits, mais nous travaillons pour nous améliorer chaque jour. Merci de votre patience et d'être resté avec nous. Nous pouvons le faire ensemble !

@hamiddd1980 Vous serez heureux d'apprendre que nous avons beaucoup travaillé sur RTL ces derniers mois. J'espère que cela améliore votre expérience!

@samhouts N'oubliez pas que vous n'êtes pas un produit final de Xamarin. Nous avons besoin non seulement de patience, mais aussi de beaucoup de ressources humaines et d'argent. Tout bogue ouvert et vérifié dans github doit être corrigé dès que possible car il crée un effet boule de neige sous forme de dette technique, de colère et de tensions inutiles avec nos clients.

Veuillez corriger plus de bugs, n'ajoutez pas plus de fonctionnalités. Stabilité sur fonctionnalité. Vous avez encore 1 590 bugs vérifiés https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A% 22

@samhouts merci pour votre réponse. 1-2 fusion par jour est extrêmement moins. Je travaille sur d'autres outils multiplateformes et ils ont 15 fusions par jour 455 fusions le mois dernier. J'aime toujours plus Xamarin en tant qu'outil et je suis prêt à contribuer toujours, mais ma fusion a pris plus de 2 mois et j'ai dû créer cette fusion 3 fois avec une nouvelle base à partir d'une branche différente.
A côté de cela, il y a un problème de priorité de votre côté. Les gens recherchent désespérément des correctifs pour les outils de base tels que les bogues Device.Idiom.. ou CollectionView, etc.
Aujourd'hui, il y a eu un grand progrès en effet 8 fusions au total jusqu'à présent. Mais pour être honnête, en dessous des fusions, moins de gens sont intéressés par la vue par balayage, les pinceaux ou les thèmes dégradés, etc. lorsque des PR aussi critiques sont en file d'attente pendant des mois. C'est la plus grande frustration je crois

Tout bogue ouvert et vérifié dans github devrait être corrigé dès que possible

C'est évidemment irréaliste ; même si Microsoft a considérablement augmenté la taille de l'équipe Xamarin.Forms.
Travaillez plus intelligemment, pas plus dur, disent-ils (dans ce cas, cela devrait signifier exiger des PR qu'ils incluent des tests de régression pour s'assurer que les bogues ne réapparaissent pas ; cependant, comme pour tout, c'est aussi un compromis, car les critiques des contributions Les PR deviendront plus longs et plus difficiles).

Veuillez corriger plus de bugs, ne pas ajouter plus de fonctionnalités

C'est un avis que je partage aussi. Cependant, à proprement parler, le plan de transition MAUI<>Xamarin.Forms couvre déjà cela : Xamarin.Forms passera uniquement en mode de correction de bogues, tandis que les nouvelles fonctionnalités n'atteindront que Maui.

(dans ce cas, cela devrait signifier exiger des PR qu'ils incluent des tests de régression pour s'assurer que les bogues ne réapparaissent pas ; cependant, comme pour tout, c'est aussi un compromis, car les examens des PR contribués deviendront plus longs et plus difficiles).

Absolument. C'est un compromis avec lequel nous avons également eu du mal. Nous avons des milliers (!) De tests automatisés et nous les exécutons sur plusieurs appareils. Le problème est qu'il leur faut des heures (actuellement environ 4 heures par exécution et par appareil) pour les terminer, et ils sont parfois, malheureusement, un peu floconneux pour un certain nombre de raisons. Par exemple, je viens de contacter un contributeur hier à propos d'un test qui, selon moi, échouait légitimement, pour me rendre compte qu'il échouait en fait parce que Chrome nous demandait d'accepter les nouvelles conditions d'utilisation. ??

Cela entraîne beaucoup de retards, et cela signifie que les PR peuvent parfois prendre des jours juste pour passer les tests. C'est à nous, et c'est un problème que nous devons résoudre.

Heureusement, nous travaillons sur ce problème. Nous développons une nouvelle méthode de test des moteurs de rendu de plate-forme qui ressemble davantage à des tests unitaires qu'à une automatisation réelle de l'interface utilisateur, ce qui est beaucoup plus fiable et plus rapide.

En ce qui concerne l'ajout de nouvelles fonctionnalités plutôt que la correction de bogues... comme le dit

Sachez que nous pensons toujours à vous et à vos clients lorsque nous apportons des modifications, et nous écoutons vos commentaires.