Release 3.3 stable
-
@nosh2 je ne comprends pas cette phrase, peux tu développer ?
et je suis rester surpris de voir un émulateur qui se compiler a un moment sur un fork de rockaddicted.
-
Bon je vais répondre que pour les critiques porté envers ma personne. Donc voila la phrase dite si virulente que cela choque toutes l'équipe de Recalbox.
Je pense que la gestion du projet devient hasardeuse maintenant, beaucoup trop de contribution font que ça part de tous les côtés, imaginer qu’il existe déjà une 4.1.
Bon je met en évidence certain des mots qui semble être bloquer par adblock. Donc je pense dis que c'est mon opinion vue de l'extérieur, par omision le devient dis que le projet n'est pas hasardeux et aussi qu'il n'est pas encore, je donne après ma raison même si j'en suis fautif aussi car je bosse dans mon coin mais je vais répéter le pourquoi "je n'ai pas encore les connaissance technique pour pouvoir contribuer de manière propre au projet et maintenant je n'en ai pas l'envie a cause du comportement que vous avez envers certaines personnes que vous envoyer dans les roses sur le chan irc" mais c'est ma contribution que j'essaye d'apporter a recalbox comme le fait d'essayer d'aider le plus de monde sur le chan irc. Donc maintenant j'aimerais bien qu'on arrête d'utiliser une appréciation erroné de ce qui a été écris. C'est si facile de faire dire aux autres des propos. Ca me rappelle @rockaddicted qui avait mal après l'insulte que je lui est dis en disant qu'il avait une chasse gardée sur les core libretro.
Définition : Chasse gardée - Domaine, activité que l'on se réserve.
Ce qui est maladroits mais qui été le terme le plus proche de l'idée que d'arriver a compiler et integrer un core libretro avant @rockaddicted été difficile. --------------------------------------- @rockaddicted : https://github.com/recalbox/recalbox-buildroot/blob/af13f314924b99e0e3c019df56afff351400b369/package/libretro-mupen64/libretro-mupen64.mk @MikaXII : MikaXII, je comprend pas pourquoi tu dis cela, j'avertis que sur le push, il manque des fichiers sur les deux derniers push ou j'ai oublier des dossiers et que je dois donc upgrader le script mais pour cela il me faut un moment libre ou je peut redownloader le buildroot pour rajouter les modifications. Donc des fois ca sert de regarder les fichiers qu'on a merger. Sinon caveut dire que c'est cool que mes pushs vont peut être intégrer recalbox. Car c'est chiant de devoir a chaque fois les installer.
-
... Non non y a pas d'adblock "Je pense" à partir du moment où il y a "je pense" c'est du jugement tu émets ton opinion. De plus la je vais le dire avec toute franchise car ton jeu du calimero m'épuise :
pourquoi “je n’ai pas encore les connaissance technique pour pouvoir contribuer de manière propre au projet et maintenant je n’en ai pas l’envie a cause du comportement que vous avez envers certaines personnes que vous envoyer dans les roses sur le chan irc”
Je vais parler de moi, je suis arrivé il y a environ un an, buildroot je ne connaissais pas du tout, j'ai voulu participé j'ai demandé tout simplement comment on fait. J'ai le souvenir d'avoir été aidé, accueilli comme il le fallait. @digitallumberjack a prit parfois de son temps perso pour m'expliquer les choses... Et le pire c'est que ça je le vois encore avec des utilisateurs plus ou moins nouveau comme Ian57 ou plus recemment PasNox avec docker. "Chasse gardé" la aussi ça me trou le cul de voir ça. @Florian franchement sir ironic et voljega si même des fois on se prend la tête eux savent quand il faut arrêter et nous aussi, toi non tu continues tu ne t'arrêtes pas. Si tu n'arrêtes de faire ta victime et ton calimero franchement quitte l'aventure, fork. mais sérieusement tu nous les brises. Si t'es pas capable d’intégrer une communauté parce que ça ne marche pas comme tu veux ça ne fonctionnera pas. Stop ici et tout le monde se sentira mieux toi y compris. EDIT : Encore une anecdote, tu vois le recalbox-manager l'idée original c'est moi mais avec un soucis de choix de techno et de temps @sveetch à pris le projet. Bien sur ça m'a saoulé au début mais je suis toujours là et j'ai moi même aidé sveetch à intégrer le manager en tant que package. Je suis toujours là et j'ai jamais cassez les couilles à sveetch. Dans une communauté on s'adapte au avis divergent mais on ne fait pas passer ses idées en force si elles ne sont pas acceptés. Donc si ce que tu fais est rejeté par un ensemble d'utilisateurs tu t'écrases ou tu forks mais tu arrêtes de pleurer.
-
@nosh2 hummm comme tu le vois bien ce core (inutilisé) n'est pas compilé depuis "mon fork" : https://github.com/recalbox/recalbox-buildroot/blob/rb-4.0.X/package/libretro-mupen64/libretro-mupen64.mk#L11
#LIBRETRO_MUPEN64_VERSION = 53c38fefaf51d5c18af23f9eaceab32e80c4034c #LIBRETRO_MUPEN64_SITE = $(call github,libretro,mupen64plus-libretro,$(LIBRETRO_MUPEN64_VERSION)) ##LIBRETRO_MUPEN64_VERSION = bd444b70a522a56e3cbc72a295d38325ddc35232 ##LIBRETRO_MUPEN64_SITE = $(call github,rockaddicted,mupen64plus-libretro,$(LIBRETRO_MUPEN64_VERSION)) LIBRETRO_MUPEN64_VERSION = a72d5c0b5a8f1a4700ebf7727fa50b8e52a373d8 LIBRETRO_MUPEN64_SITE = $(call github,gizmo98,mupen64plus-libretro,$(LIBRETRO_MUPEN64_VERSION))Mais depuis un dépôt github, qui a l'époque, proposait une version corrigée pour fonctionner sur le rpi ... Tu vois bien que le liens vers mon fork est commenté, uniquement utilisé lors de tests de compilation. Ce core n'ayant jamais vraiment fonctionné sur le rpi, la décision a été prise de rester sur la version standalone de l'émulateur et le package de test libretro-mupen64 n'a jamais été "nettoyé"...
-
Pourquoi je quitterait recalbox, aujourd'hui il manque des choses importantes pour moi et je n'ai jamais eu dans ma logique de ne pas partager mes avancées surtout sur un projet opensource. Je suis vraiment aussi horrible de proposer des choses a recalbox. Et le calimero sérieux tu me le sort d’où, juste parce que je connais mes limites et que je pense que ça serait dangereux que j'essaye maintenant de travailler sur autres choses que des émulateurs. Et si ce que j'ai dis te trou le cul (vulgarité quand tu nous tiens), je me demande si on vie dans le même monde car pour moi c'est loin d'être si virulent que cela. Surtout avec ce que je prend dans la tête tous les jours. Peut être que j'ai des limites qui sont devenue plus fou que certain ici. Non sérieux, ce qui est écris sur le forum n'est pas anodin et accessible a tous, donc vous comprenez que je peut non plus me laisser insulter sans y répondre. Et sérieusement je cherche même pas a avoir le dernier mot mais a vous faire comprendre que ce que vous dite n'est pas ce que j'ai écris, et ça devient lourd d’être critiquer sans être lu. @rockaddicted, merci de tes précisions mais je suis pas bêtes et je sais très bien que ce package est inutile actuellement, mais il représenter un bon exemple et parler du fait que vous voulez pas de ports, puis maintenant si mais pas comme retropie. Et comme le faite qu'on garde pas simplelight et qu'il est maintenant gardé, qu'on se concentre sur libretro et qu'on integre dosbox au lieu de dosbox-libretro, comme la psp aussi.
-
Je suis spamé de mails qui ne me concérne pas, ça saoul !
-
Et le calimero sérieux tu me le sort d’où
Le mec vexé qui supprime c'est compte github/forum etc ça fais pas calimero ?
et ça devient lourd d’être critiquer sans être lu
Si si justement on lit mais toi tu ne te relis pas, tu ne te rend pas compte que tu joues la provoc. Pour finir il n'y as pas de chasse gardé, j'ai commencé le package sur supermariowar mais Sub l'a fini car je galérer qu'est-ce qu'il t’empêche d'apporter ta contribution à un package en cours de réalisation ? Rien, absolument rien ton ego et ta fierté de vouloir faire tout de A à Z mais la encore c'est pas l'esprit communautaire. Partage oui mais fais des package testé fonctionnel qui apporte une plus value. Pas quelque chose d'inachevé. EDIT : Pardon @Florian mais je savais pas qu'il était possible d'avoir 2 usernames identiques Oo
-
@Florian , tu peut supprimer les notifications par le menu edition de ton compte. Après ce bug est sûrement du a un forum mal codé qui envoie des notifications par rapport au pseudo et non au compte. Edit : Désolé, je croyais que mon pseudo été la cause, et je n'avais pas remarquer les quotes de MikaXII.
-
sérieux, vous avez du temps à perdre pour nourrir les trolls ? C'est tellement ennuyeux que je n'ai meme pas cherché à lire au-delà de la 2e page
OSEF les numéros de version ! y'a des nouveautés, faut mettre à jour, point barre, et faire son retro geek ! Si c'était mieux avant, à votre aise ! y'a meme la 3.2.11 ! Tiens allez un coup de sonnette à @Florian histoire de le taquiner 
(haha, désolé mec, c'est pour faire comme tout le monde sur le topic, pardonne-les, ils confondent avec Nosh2 
) -
@rockaddicted, merci de tes précisions mais je suis pas bêtes et je sais très bien que ce package est inutile actuellement, mais il représenter un bon exemple
Un bon exemple de quoi ? C'est un package expérimental sur lequel nous faisions des tests de correctifs pour pouvoir utiliser ce core sur le raspberry pi et par la suite proposer ces fix upstream chez libretro afin que que l'ENSEMBLE de la communauté raspberry, toute distributions confondues, puissent en profiter... Je ne vois pas ce qu'il y a de choquant la dedans. C'est la procédure habituelle...
parler du fait que vous voulez pas de ports, puis maintenant si mais pas comme retropie.
Ou as tu péché le fait que nous ne voulions pas intégrer de "ports", c'est à dire, des portages de jeux sous linux ? Ça a toujours était dans la todo list, sinon nous aurions clôturé toutes les demandes d'ajout présentes sur github (certaines vieilles de plus 1an). C'est juste que pour que ce soit bien fait, cela demande autant de travail d'ajouter un seul jeu qu'un émulateur standalone. Création du package de compilation, intégration au système, et faire un configgen custom pour chaque jeu. Donc c'est juste que nous avons d'autres priorité pour le moment, mais le moment venu, nous bosserons dessus. Le projet recalbox est fait le temps libre de chaque contributeurs.... donc ça prendra le temps que ça prendra....
Et comme le faite qu’on garde pas simplelight et qu’il est maintenant gardé
Et bien didons... tu m'en apprends des choses ce soir... Moi qui pensais pourtant être bien informé sur les coulisses du projet, je me trompe... Enculé de @retroboy va ... merci de me faire des cachotteries
Depuis la création de ce post (et même bien avant) http://blog.recalbox.com/forums/topic/new-theme-we-need-you/ il a été annoncé de façon officielle que le thème par défaut de recalbox allait bien changer, au profit d'un nouveau thème écrit intégralement from scratch, et avec des vectos maison faites par la communauté (en grand merci à tous ceux qui participent à ce projet). Mais comme tout projet, cela ne se réalise en claquant des doigts.... Surtout quand on ne choisi pas la facilité en voulant vectoriser à la mano les différents éléments composant les thèmes des 45systèmes de la 4.0.0... Cela prend du temps. Sans parler après du job de création du thème en lui même. Donc oui, sur les 2 premières versions de la bêta, nous avons laissé le thème simplelight par défaut afin de pas fournir un version pré-release à poil niveau thème. Auriez vous apprécié avec une interface sans thème, ni mise en forme ?! Je ne pense pas, et moi non plus d'ailleurs... Mais actuellement nous avons environ 75% des systèmes de vectorisés, donc dans la prochaine bêta, une pré-release du thème sera proposé pour recueillir les feedbacks, en vue d'une intégration définitive du thème dans la 4.0.0 stable, en remplacement de simplelight. Encore une fois... je ne vois pas ce qu'il y a de choquant la dedans.qu’on se concentre sur libretro et qu’on intègre dosbox au lieu de dosbox-libretro, comme la psp aussi.
Oui en effet, la politique a toujours été et sera toujours de tester les core libretro en priorité pour un système et si ces derniers nous satisfasse, dans le cadre d'une utilisation sur les raspberry on part la dessus. Cela a l'avantage de faciliter son intégration dans le système et de pouvoir bénéficier du formidable travail accompli par la team libretro et des fonctionnalités avancées de retroarch. Mais malheureusement, quand un core ne nous satisfait dans le cadre de l'utilisation que l'on souhaite en faire, on le compare avec une solution en standalone. Dans le cadre de dosbox, car tu en parle, un membre de la communauté, nous a proposé une version totalement fonctionnelle de dosbox standalone, avec une intégration parfaite dans le système et cerise sur le gâteau, son configgen complet et fonctionnel. Sachant que le core libretro-dosbox présente des gros soucis de clavier ainsi que de performance. Nous aurions été débiles de ne pas intégrer ceci au projet. De même pour la psp, avec l'arrivée du rpi3, son intégration dans le système devient envisageable, même si nous seront encore très loin d'une émulation parfaite de cette machine sur cette génération de rpi. Etant donné que l'on souhaite l'intégré, nous avons, en interne, effectué des tests de performance entre la version libretro et la version standalone. Dans les mêmes conditions, avec les mêmes jeux, on observe en moyenne un gain de perf de l'ordre de 10% avec la version standalone. Alors certes dans un soucis de facilité nous pourrions très bien partir sur le choix d'intégrer la version libretro de ppsspp, ça nous arrangerai bien. Mais étant donnée que le rpi3 crache déjà ses tripes sur l'émulation de cette machine, nous avons jugé que 10% de perf en plus étaient loin d'être négligeable... Donc nous avons décidé de partir sur la version standalone, ce qui pour nous ne représente pas du tout la même charge de travail...
-
Toujours autant d'ego et d'orgueil... Ça devrait pourtant vous faire réfléchir un peu que ce qu'on prédisait sur la confusion dû au numérotage des versions dans notre "philosophie de comptoir" s'est produit mais non vous préférez continuer continuer continuer. Enfin quand on arrive à être agressif comme ça face à de simples utilisateurs sans même réaliser que l'attitude aussi fait partie de la 'compétition' entre distributions... http://blog.recalbox.com/forums/topic/rpi3-support-for-v3-x-not-just-v4-x/
-
/mode collaborateur au projet : ON @Voljega, et il me semble que lors de cette "discussion de comptoir" @retroboy a expliqué clairement le raisonnement ayant poussé à prendre cette décision. Ce choix peut très bien ne pas te satisfaire, soit. Mais à un moment donné, il faut voir le problème dans son intégralité. 2 versions d'un même système radicalement différentes en terme de fonctionnement interne, ayant chacun une structure et un mode d'update propre. Cela se traduit par 2 versions à maintenir simultanément en terme de support technique, documentation et infrastructure serveur (et oui, les maj OTA ne tombent pas du ciel... tout comme les builds... il y a de gros serveur privés derrière recalbox, payé chaque mois par @retroboy.) Maintenant qu'est ce qui a bien pu nous passer par la tête pour nous lancer sur le chantier de la 4.0.0, alors que nous avions, en effet une 3.3.0 qui, en apparence, était prête à tourner au poil de cul en versions table?! Et bien sachez que ce n'est pas parce que vous n'avez, personnellement, jamais eu de soucis avec, que tout le monde se trouve dans la même situation. En effet, au cours de la phase de dev de la 3.3.0, nous avons reçu énormément de feedback négatifs concernant le système d'update utilisant rsync ainsi de niquage du FS... Les 2 entraînant simplement la corruption intégrale du système et obligeant une réinstallation complète du système. A ce moment là, nous nous retrouvions alors face à 2 choix : - 1, la facilité : fermer les yeux devant ces soucis, et continuer recalbox avec un système de base en 3.3.x. Nous serions alors parti du principe que ce n'était pas vraiment un souci, étant donné que ces problèmes étaient "relativement" rares... Nous pouvions continuer ainsi et partir du principe que si les utilisateurs devaient refaire une fresh install toutes les X updates et bien soit, chacun sa merde. La 3.3.0 étant alors à 2 doigts de passer en release en stable, cela nous aurait bien arrangé la vie... -2, la sécurité : ouvrir les yeux face à ces soucis et trouver des solutions à ces problèmes. Les solutions étaient connues et devaient à la base être intégrée dans une version lointaine de recalbox étant donné la masse de travail que cela représentait. Mais finalement, après de lonnngues discussions, nous avons décidé d'avancer ces milestones et de bosser sur les nouvelles features comme le passage du système en read-only et la refonte complète du système d'update du système, afin de garantir un plus grande stabilité au système. Le système d'update n'utilisant plus rsync, devenait alors incompatible avec le système mis en place dans les versions antérieurs de recalbox. Nous étions conscient des désagréments utilisateurs que cela engendrerai pour les utilisateurs, notamment pour ceux ayant déjà un installation en 3.3.0 beta (confusion dans les numéros de versions, obligation de repartir sur une fresh install pour passer d'une 3.3.0 à une 4.0.0 etc...) Mais à un moment donné, lorsque l'on voit que l'on fonce droit dans un mur, il faut savoir changer de direction... Après certes, nous aurions très bien pu, continuer sur la branche 3.3.0, et intégrer ces modifications dans une énième beta... Car en fait, la 4.0.0 n'est rien d'autre qu'une 3.3.0 avec un système en read only et un nouveau système d'update + quelques ajouts "mineurs". Mais justement cette "cassure" en terme de fonctionnement interne de l'OS, nous a poussé à changer de branche pour la 4.0.0 , afin de marquer l'impossibilité de migrer d'une 3.3.0 vers une 4.0.0 . Par la même occasion, nous avons mis en place un système à 3 sous-branches (unstable, beta, stable) afin séparer chaque stade de développement d'une même version (et oui nous avons beaucoup appris durant cette période) et permettre facilement à chaque utilisateur de choisir laquelle il souhaite utiliser en modifier une simple ligne dans le recalbox.conf Maintenant, ces choix ne te plaisent peu être pas, mais il fallait prendre des décisions et il faut faire avec. Impossible de satisfaire la totalité des utilisateurs à chaque fois. Nous essayons de raisonner en terme de bénéfices globaux pour l'ENSEMBLE des utilisateurs et le système à chaque prise de décision. /mode modo : ON Je trouve inadmissible la tournure que prend cette discussion. Ce genre de discussion totalement stérile ou chacun vide son sac et ses ressentis à chaud n'apportent rien de bon ou de constructif. Uniquement ambiance pourrie dans la communauté, démotivation de la part des personnes s'investissant dans le projet et une image de projet "kévinkikoolol" à recalbox. Ce n'est malheureusement pas la première fois que cela se produit... Mais si à l'avenir cela se reproduisait, des sanctions devraient alors être prise pour préserver l'ambiance globale du projet... Je clos ce sujet.
