Ben, en fait, oui. On travaille avec deux projets libres, l'un en GPL et l'autre sous copyright attribution double licence. Dans l'un des cas on remonte les patches, dans l'autre pas (la politique, tout ça, je passe les détails). On est une très petite boite.
Donc oui, dans les faits ça me coûte moins cher en temps de remonter les patches une fois que de maintenir ma pile de patches et de les mettre à jour à chaque nouvelle version mineure du projet. Dans le premier cas il m'a fallu quelques jours pour faire accepter le patch, dans l'autre il me faut chaque fois une journée, au mieux, pour adapter les patches. Après genre cinq versions, la première façon de faire est clairement gagnante en terme de temps dépensé.
Quant à l'intérêt, encore une fois c'est l'intérêt immédiat comparé à un intérêt à plus long terme. Au moment de commencer le jeu il est bien plus facile de forker. Après un an ou deux de galère et de patches divers je me demande si certains ne préféreraient pas avoir moins de code à maintenir et utiliser un moteur commun. Moins de code à maintenir, c'est aussi plus de temps à investir dans d'autres aspects du développement, comme de nouvelles fonctionnalités, un meilleur gameplay ou de nouveaux niveaux. Cependant, passer d'un fork à l'utilisation d'un moteur commun ne se fait pas en une nuit, et donc, encore une fois l'efficacité à court terme est de conserver son fork.
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 7.
Ben, en fait, oui. On travaille avec deux projets libres, l'un en GPL et l'autre sous copyright attribution double licence. Dans l'un des cas on remonte les patches, dans l'autre pas (la politique, tout ça, je passe les détails). On est une très petite boite.
Donc oui, dans les faits ça me coûte moins cher en temps de remonter les patches une fois que de maintenir ma pile de patches et de les mettre à jour à chaque nouvelle version mineure du projet. Dans le premier cas il m'a fallu quelques jours pour faire accepter le patch, dans l'autre il me faut chaque fois une journée, au mieux, pour adapter les patches. Après genre cinq versions, la première façon de faire est clairement gagnante en terme de temps dépensé.
Quant à l'intérêt, encore une fois c'est l'intérêt immédiat comparé à un intérêt à plus long terme. Au moment de commencer le jeu il est bien plus facile de forker. Après un an ou deux de galère et de patches divers je me demande si certains ne préféreraient pas avoir moins de code à maintenir et utiliser un moteur commun. Moins de code à maintenir, c'est aussi plus de temps à investir dans d'autres aspects du développement, comme de nouvelles fonctionnalités, un meilleur gameplay ou de nouveaux niveaux. Cependant, passer d'un fork à l'utilisation d'un moteur commun ne se fait pas en une nuit, et donc, encore une fois l'efficacité à court terme est de conserver son fork.