Tu parles de payer le dév pour remonter les patches, je me demande comment quantifier les ressources gaspillées à porter les modifs de chaque appli d'une version à l'autre de XulRunner.
Quand tu suis un projet un minimum et que tu connais bien les sources, je t'assure que porter les modifs d'une version à une autre est souvent bien moins couteux que de proposer en upstream.
Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça. Corriger ton patch, ça peut être bénéfique bien sûr. Et puis il y a tout un workflow à suivre : proposition du patch, review du patch, vérifier que tout les tests passent, commiter, attendre une nouvelle fois que les tests des machines de build passent etc. Et pour Mozilla, attendre 12 à 18 semaines que ce soit dans une release officielle (et encore, avant le fast release cycle, fallait attendre 1 ou 2 ans). Pour d'autres projets, attendre peut-être des mois et des mois…
Chez Mozilla, j'ai eu des patchs refusés parce que ça impactait ou était incompatible avec tel ou tel composant externe ou appli mozilla. Le souci, c'est que moi, pour mon appli, j'en avait rien à fiche. Le patch fonctionnait parfaitement pour mon appli, c'était le principal. Parce que la majorité des applis que je développe, c'est pour des clients, ou pour mon employeur (quand j'étais salarié :-)). J'ai des délais pour réaliser une appli. Dans mon exemple, rajouter des heures et des heures pour adapter le patch pour qu'il fonctionne pour tout le monde en upstream n'aurait pas été possible dans le planning du projet. Donc voilà, pas d'intégration upstream pour certains patchs (en tout cas, pas dans un premier temps, et pas dans les délais de réalisation du projet).
Dans bon nombre d'entreprise, c'est pareil (et j'en vois plein des boites…). les patchs sont proposés en upstream que si le budget le permet, que si on a le temps, ou que si c'est vraiment critique. Ou que si la boite est impliqué à fond dans le développement de la lib, du framework etc..
Et encore, je ne parle pas des cas où il faut attendre qu'un contributeur en face se bouge pour faire la review ou commiter (quand on n'a pas le "karma" nécessaire dans le projet upstream). Et pour les projets de libs un peu mort…
Bref, voilà, ça peut être coûteux de contribuer en upstream, dans le cadre d'un projet d'entreprise. Alors oui, on se retrouve avec des applis qui nécessitent des versions personnalisées de bibliothèque, comme c'est souvent le cas avec XulRunner.
[^] # Re: à propos de XulRunner
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Une histoire de fork. Évalué à 8.
Quand tu suis un projet un minimum et que tu connais bien les sources, je t'assure que porter les modifs d'une version à une autre est souvent bien moins couteux que de proposer en upstream.
Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça. Corriger ton patch, ça peut être bénéfique bien sûr. Et puis il y a tout un workflow à suivre : proposition du patch, review du patch, vérifier que tout les tests passent, commiter, attendre une nouvelle fois que les tests des machines de build passent etc. Et pour Mozilla, attendre 12 à 18 semaines que ce soit dans une release officielle (et encore, avant le fast release cycle, fallait attendre 1 ou 2 ans). Pour d'autres projets, attendre peut-être des mois et des mois…
Chez Mozilla, j'ai eu des patchs refusés parce que ça impactait ou était incompatible avec tel ou tel composant externe ou appli mozilla. Le souci, c'est que moi, pour mon appli, j'en avait rien à fiche. Le patch fonctionnait parfaitement pour mon appli, c'était le principal. Parce que la majorité des applis que je développe, c'est pour des clients, ou pour mon employeur (quand j'étais salarié :-)). J'ai des délais pour réaliser une appli. Dans mon exemple, rajouter des heures et des heures pour adapter le patch pour qu'il fonctionne pour tout le monde en upstream n'aurait pas été possible dans le planning du projet. Donc voilà, pas d'intégration upstream pour certains patchs (en tout cas, pas dans un premier temps, et pas dans les délais de réalisation du projet).
Dans bon nombre d'entreprise, c'est pareil (et j'en vois plein des boites…). les patchs sont proposés en upstream que si le budget le permet, que si on a le temps, ou que si c'est vraiment critique. Ou que si la boite est impliqué à fond dans le développement de la lib, du framework etc..
Et encore, je ne parle pas des cas où il faut attendre qu'un contributeur en face se bouge pour faire la review ou commiter (quand on n'a pas le "karma" nécessaire dans le projet upstream). Et pour les projets de libs un peu mort…
Bref, voilà, ça peut être coûteux de contribuer en upstream, dans le cadre d'un projet d'entreprise. Alors oui, on se retrouve avec des applis qui nécessitent des versions personnalisées de bibliothèque, comme c'est souvent le cas avec XulRunner.