L'histoire de l'inclusion de la pile CAN me rappelle les problèmes que l'on a ici sur l'inclusion de chose dans Linux. Je me rappelle aussi les appels/voeux pieux de Linux concernant le fait d'intégrer de nouveau codeur plus gentiellement/facilement.
1 an, semble énorme pour beaucoup d'entreprise. J'ai lu un peu les threads d'échange pointé par les différentes articles.
So we have to be patient and i personally have to perform the task "It is therefore your responsibility to make the work interesting to the networking developers and fun to review." given by David Miller ...
But this task is hard to perform, when there's no feedback from the netdev guys and when it's not very interesting by design (of CAN) ;-( I have no idea when PF_CAN becomes that interesting to the major players like Patrik McHardy and David Miller, so that the code gets finally reviewed. I assume that is no sufficient answer for your question. Btw. i backed off for two weeks now and i'm patient.
J'aime particulièrement le passage ou il est dis que les nouveau venu doivent montrer du code intéressant pour être revu... J'imagine la tête des équipes soft avec ce genre de "requirement"....
J'ai vraiment l'impression qu'il y a une différence entre la volonté affiché d'intégrer et d'accueillir les nouveaux venu et la réalité. La réalité, c'est la liste des mainteneurs juste en dessous de Linus, qui décide réellement si votre sous-système est digne d'intérêt. Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).
En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
En tout cas, cela n'encourage pas du tout à pousser sa boite à se mettre dans la boucle...
# Coder pour linux
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.25 est disponible. Évalué à 8.
1 an, semble énorme pour beaucoup d'entreprise. J'ai lu un peu les threads d'échange pointé par les différentes articles.
So we have to be patient and i personally have to perform the task "It is therefore your responsibility to make the work interesting to the networking developers and fun to review." given by David Miller ...
But this task is hard to perform, when there's no feedback from the netdev guys and when it's not very interesting by design (of CAN) ;-( I have no idea when PF_CAN becomes that interesting to the major players like Patrik McHardy and David Miller, so that the code gets finally reviewed. I assume that is no sufficient answer for your question. Btw. i backed off for two weeks now and i'm patient.
J'aime particulièrement le passage ou il est dis que les nouveau venu doivent montrer du code intéressant pour être revu... J'imagine la tête des équipes soft avec ce genre de "requirement"....
J'ai vraiment l'impression qu'il y a une différence entre la volonté affiché d'intégrer et d'accueillir les nouveaux venu et la réalité. La réalité, c'est la liste des mainteneurs juste en dessous de Linus, qui décide réellement si votre sous-système est digne d'intérêt. Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).
En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
En tout cas, cela n'encourage pas du tout à pousser sa boite à se mettre dans la boucle...
"La première sécurité est la liberté"