Bah, ils ne vont pas non plus faire des remontées upstream quand ça ne les arrange pas...
C'est une question de stratégie. Si tu penses que ton module ou ta modification des API peut bénéficier à d'autres et que ça t'arrangerait de factoriser la maintenance, alors tu as tout intérêt à contacter les devs upstream, à négocier le bout de gras avec eux (puisqu'ils n'ont aucune raison d'accepter du code supplémentaire sans en voir l'intérêt), et à envoyer des patches.
Si par contre il est évident que ça va être très très galère, que ta stratégie est nettement différente de celle des autres projets, voire que ton fork est limite inamical, je ne vois pas à quoi ça sert de perdre de l'énergie à tenter de faire passer tes modifs au dessus, puisqu'au final elles ne passeront pas, ou pas comme tu veux, et que le temps que tu as passé à convaicre le projet upstream, tu ne l'auras pas passé à débugger ou à améliorer ton fork.
Quand Google a développé Android, ils n'ont pas tenté de passer leurs patches dans le noyau officiel : ils étaient beaucoup trop occuppés à faire un truc qui marche pour en plus se mettre une telle contrainte sur le dos. Je pense que c'est pareil pour Unity par exemple, et que ça correspond à la bonne stratégie : Ubuntu veut une interface graphique "Made in Ubuntu" et prétend être plus qu'un intégrateur de paquets. Je les vois mal envoyer des mails du style "Cher Monsieur Gnome, on a forké votre interface parce qu'on la trouvait pourrie, merci de bien vouloir intégrer mon code plein de bugs / fonctionnalités dans votre dépot parce qu'on a du mal à débugguer ça tout seuls"...
[^] # Re: Un petit rappel
Posté par arnaudus . En réponse au journal Intel boycotte officiellement le serveur d'affichage Mir. Évalué à 6.
Bah, ils ne vont pas non plus faire des remontées upstream quand ça ne les arrange pas...
C'est une question de stratégie. Si tu penses que ton module ou ta modification des API peut bénéficier à d'autres et que ça t'arrangerait de factoriser la maintenance, alors tu as tout intérêt à contacter les devs upstream, à négocier le bout de gras avec eux (puisqu'ils n'ont aucune raison d'accepter du code supplémentaire sans en voir l'intérêt), et à envoyer des patches.
Si par contre il est évident que ça va être très très galère, que ta stratégie est nettement différente de celle des autres projets, voire que ton fork est limite inamical, je ne vois pas à quoi ça sert de perdre de l'énergie à tenter de faire passer tes modifs au dessus, puisqu'au final elles ne passeront pas, ou pas comme tu veux, et que le temps que tu as passé à convaicre le projet upstream, tu ne l'auras pas passé à débugger ou à améliorer ton fork.
Quand Google a développé Android, ils n'ont pas tenté de passer leurs patches dans le noyau officiel : ils étaient beaucoup trop occuppés à faire un truc qui marche pour en plus se mettre une telle contrainte sur le dos. Je pense que c'est pareil pour Unity par exemple, et que ça correspond à la bonne stratégie : Ubuntu veut une interface graphique "Made in Ubuntu" et prétend être plus qu'un intégrateur de paquets. Je les vois mal envoyer des mails du style "Cher Monsieur Gnome, on a forké votre interface parce qu'on la trouvait pourrie, merci de bien vouloir intégrer mon code plein de bugs / fonctionnalités dans votre dépot parce qu'on a du mal à débugguer ça tout seuls"...