Je ne me plaint ni ne blâme personne. J'essaye de réfléchir à des techniques qui peuvent résoudre ce genre de problème. Parmi des solutions déjà trouvée, citons :
- bugzilla
- modularisation plus importante (cf. le projet de Xorg de modulariser X), mais ça relève plus des bonnes pratiques que d'innovations
- Maven : utilisé pour Struts, je trouve que cet outil aide plus à la création d'un projet que pour les contributeurs. AMHA, ça vient du fait qu'un outil "intelligent" a beaucoup trop de comportements "implicites". C'est une autre histoire...
- Intégration d'un projet à un IDE, pour les normes de codage, notamment.
Pour moi, ce qui a vraiment posé problème avec Struts, c'est
1 - la mauvaise gestion des branches : des branches servent à maintenir des versions anciennes et d'autres servent pour les prochaines releases. On ne sait donc pas trop sur laquelle travailler. Ils en sont conscients, ils y travaillent...
2 - la mauvaise modularisation. Pour les releases, ont a un seul jar. Pour développer il faut créer plusieurs jar pour pouvoir travailler sur une partie et ne pas tout reconstruire à chaque fois. Mais du coup, le projet n'a pas la même architecture quand on développe et quand on release. Encore une fois, ça devrait évoluer.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: contribuer à un gros projet
Posté par Jean Parpaillon . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
- bugzilla
- modularisation plus importante (cf. le projet de Xorg de modulariser X), mais ça relève plus des bonnes pratiques que d'innovations
- Maven : utilisé pour Struts, je trouve que cet outil aide plus à la création d'un projet que pour les contributeurs. AMHA, ça vient du fait qu'un outil "intelligent" a beaucoup trop de comportements "implicites". C'est une autre histoire...
- Intégration d'un projet à un IDE, pour les normes de codage, notamment.
Pour moi, ce qui a vraiment posé problème avec Struts, c'est
1 - la mauvaise gestion des branches : des branches servent à maintenir des versions anciennes et d'autres servent pour les prochaines releases. On ne sait donc pas trop sur laquelle travailler. Ils en sont conscients, ils y travaillent...
2 - la mauvaise modularisation. Pour les releases, ont a un seul jar. Pour développer il faut créer plusieurs jar pour pouvoir travailler sur une partie et ne pas tout reconstruire à chaque fois. Mais du coup, le projet n'a pas la même architecture quand on développe et quand on release. Encore une fois, ça devrait évoluer.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier