La fondation Eclipse utilise Hudson, vers la fin de Jenkins ?

[jmini]

Suivant le principe «Eating your own dog food» (le fait d'utiliser ses propres produits afin d'en voir les qualités et les défauts [via Wikipedia]), la fondation Eclipse utilise la version 3.0.0-RC3 d’Hudson pour son instance sandbox.

La branche 3 d’Hudson désigne le développement de l’usine logicielle effectué dans le giron de la fondation Eclipse.

Pour mémoire, après le conflit qui avait opposé la communauté à Oracle, Oracle avait décidé de poursuivre le développement d’Hudson au sein de la fondation Eclipse.

La version 3.0.0 n’est pas encore officiellement sortie (la date évoquée est le 1er novembre). Il semblerait que la fondation Eclipse l’ait jugée suffisamment stable pour commencer à l’utiliser. (Il s’agit peut-être aussi de tester cette nouvelle version grandeur nature).

Une liste des nouveautés sera certainement publiée lors de la sortie officielle. Il ne faut cependant rien attendre de révolutionnaire.

Le gros du travail a consisté à nettoyer le code et les librairies qui n’étaient pas conformes en terme de propriété intellectuelle. Comme toutes les fondations de ce type, la fondation Eclipse dispose de règles strictes et d'outils pour garantir que le code hébergé répond à certains standards. Regroupées sous le terme d'IP Cleanliness (IP pour Intellectual Property), ces règles nécessitent par exemple d'éliminer toute dépendance à un projet sous licence LGPL qui n'est pas compatible avec la licence EPL (par exemple JFreeChart).

Depuis début 2011, le projet Jenkins a continué son évolution. Ce projet représente la suite naturelle de la branche 2.x d’Hudson. Il en a gardé son modèle de développement : des petites releases fréquentes (toutes les 1 à 2 semaines).

On se retrouve donc avec deux projets proches, mais seulement partiellement compatibles.

La vision d’Eclipse Hudson est de devenir un projet avec des processus de développement, de release plus structurés. L’architecture interne d’Hudson 3.x devrait d'ailleurs continuer à évoluer : certaines briques internes devraient être remplacées pour être plus proches des standards.

On imagine pas la fondation Eclipse utiliser autre chose qu’Hudson. Reste à savoir si les deux projets Jenkins et Hudson pourront co-exister longtemps.

https://hudson.eclipse.org/sandbox/

[fregolo52]

Envoyé par jmini

On se retrouve donc avec deux projets proches, mais seulement partiellement compatibles.
On imagine pas la fondation Eclipse utiliser autre chose qu’Hudson. Reste à savoir si les deux projets Jenkins et Hudson pourront co-exister longtemps.

C'est exactement la même problématique qu'avec OpenOffice vs LibreOffice.

[ValCapri]

Oui, en effet, il serait cool que les développeurs Jenkins rejoigne le projet Hudson à partir de la version 3.0. Quitte à faire "2" versions, une version "non stable" releasé 1 à 2 semaines (genre de milestone comme pour Eclipse) et une stable releasé quand elle est prête.

Surtout que la guerre avec Oracle pour OpenOffice et Hudson n'ont plus beaucoup de sens, vu qu'ils ont été donné à des fondations (Apache et Eclipse). Ils seront bon de travailler sur une fusion, car ça me donne l'impression qu'il y a de l'énergie gâchée.

Le seul "hic" avec Oracle reste Solaris et MySQL qui n'ont plus vraiment le caractère Open Source qu'ils avaient avant. Je vois mal MariaDB, Percona et MySQL fusionnés.

[jmini]

Envoyé par fregolo52

C'est exactement la même problématique qu'avec OpenOffice vs LibreOffice.

On est d'accord. C’est un beau gâchis d’énergie au final.

Je ne sais pas quels sont les soutiens pour Apache OpenOffice. Pour Eclipse Hudson, il y a quand même pas mal de boites derrière le projet à la fondation Eclipse (Oracle, Sonatype, Tasktop, WMWare…). S’ils arrivent vraiment à moderniser/standardiser le cœur d’Hudson, ça peut être très cool et faire une belle version 3.
Jenkins en tant que Version 2 +++ a également un bel avenir.

Quant au changement de licence (EPL dépendance contrôlées et contre MIT + divers), je ne suis pas certain que cela intéresse les utilisateurs finaux.

[Teocali]

Je ne sais pas pour Hudson & Jenkins, mais pour LibrOffice/Open Office, le principal probleme vient d'un probleme de license, a ce que j'ai compris. la fusion de ces deux projets seraient difficile, non pas d'un point de vu technique, mais parce que leur license sont incompatible...
Mais bon, faudrait que je me penche un peu plus sur ce probleme

[romaintaz]

Pour moi, le divorce Hudson / Jenkins est bel et bien consommé, et je les vois difficilement se réconcilier.
Certes Hudson a nettoyé son code, le rendant sans doute plus facile à évoluer... mais ce qui fait la force de ces serveurs d'intégration continue, c'est avant tout la communauté et les plugins. Et de ce côté-là, Jenkins a une avance phénoménale par rapport à son "ex", et la lourdeur des processus de la fondation Eclipse ne va certainement pas inciter les développeurs à revenir sur Hudson.

[Freem]

Envoyé par jmini

Le gros du travail a consisté à nettoyer le code et les librairies qui n’étaient pas conformes en terme de propriété intellectuelle. Comme toutes les fondations de ce type, la fondation Eclipse dispose de règles strictes et d'outils pour garantir que le code hébergé répond à certains standards. Regroupées sous le terme d'IP Cleanliness (IP pour Intellectual Property), ces règles nécessitent par exemple d'éliminer toute dépendance à un projet sous licence LGPL qui n'est pas compatible avec la licence EPL (par exemple JFreeChart).

La (pauvre) présentation de EPL en français indique une incompatibilité avec la licence GNU GPL, mais pas avec GNU LGPL (que ce soit implicitement ou explicitement).
Serait-il possible d'avoir plus d'infos au sujet des différences? Parce que même si GPL et LGPL sont plutôt célèbres, je ne crois pas avoir souvent croisé la EPL? (Après, je suis peut-être le seul)

Envoyé par jmini

Quant au changement de licence (EPL dépendance contrôlées et contre MIT + divers), je ne suis pas certain que cela intéresse les utilisateurs finaux.

Les utilisateurs finaux se moquent peut-être des licences utilisées en interne, mais il est bon de rappeler aux développeurs qu'il important de faire gaffe à ce qu'on utilise, je pense. Ca peut éviter pas mal d'emmerdes, après tout. Perso, j'aimerai pas recevoir un jour la visite de mon patron qui vienne me dire que je dois refaire du boulot déjà fait mais avec une autre lib car oracle à breveté l'API de la première, par exemple (bon, j'aurai pu utiliser apple aussi mais c'est plus sur le matos et l'esthétique eux)

Et pour Libre Office/Open Office, il semblerait que les bases de code diffèrent pas mal maintenant, vu que LO n'a pas eu la période de gel d'OOo. Bon, pas vérifié après, je ne fais que répéter quelque chose vu sur ce forum dans un post... (et j'ai pas le lien)

[jmini]

Envoyé par Freem

La (pauvre) présentation de EPL en français indique une incompatibilité avec la licence GNU GPL, mais pas avec GNU LGPL (que ce soit implicitement ou explicitement).
Serait-il possible d'avoir plus d'infos au sujet des différences? Parce que même si GPL et LGPL sont plutôt célèbres, je ne crois pas avoir souvent croisé la EPL? (Après, je suis peut-être le seul)

La EPL == Eclipse Public License. Cette licence est utilisée principalement par la fondation Eclipse et l'écosystème autour d'Eclipse.

Ta question sur l’incompatibilité EPL <-> LGPL est très pertinente. Je n’en trouve pas de trace non plus dans la FAQ consacrée à EPL.

La Proposal d’Eclipse Hudson définit les Librairies sous LGPL comme un problème légal (nécessitant un remplacement). Pour JFreeChart c’est Eclipse BIRT qui a naturellement été utilisé.

Envoyé par Freem

Et pour Libre Office/Open Office, il semblerait que les bases de code diffèrent pas mal maintenant, vu que LO n'a pas eu la période de gel d'OOo. Bon, pas vérifié après, je ne fais que répéter quelque chose vu sur ce forum dans un post... (et j'ai pas le lien)

Je pense qu'à terme, se sera également le cas pour Eclipse Hudson vs Jenkins. Eclipse Hudson se veut la version 3 d'Hudson.

Envoyé par romaintaz

Pour moi, le divorce Hudson / Jenkins est bel et bien consommé, et je les vois difficilement se réconcilier.
Certes Hudson a nettoyé son code, le rendant sans doute plus facile à évoluer... mais ce qui fait la force de ces serveurs d'intégration continue, c'est avant tout la communauté et les plugins. Et de ce côté-là, Jenkins a une avance phénoménale par rapport à son "ex", et la lourdeur des processus de la fondation Eclipse ne va certainement pas inciter les développeurs à revenir sur Hudson.

Les Plugin Eclipse Hudson ne doivent pas forcément respecter la licence EPL. À partir du moment où ils sont installé séparément...

Je suis d'accord avec toi, pour qu'Eclipse Hudson gagne, il faut que le retour sur investissement (en terme de nettoyage de code), se traduise par un développement plus simple pour les plugins. Sinon c’est fichu pour Hudson.

La plus grosse communauté est du côté de Jenkins (~= Hudson 2.x). Et c'est un avantage non négligeable.

[eclesia]

On utilise Jenkins dans notre boite, et on le recontre souvent en dehors aussi.Il couvre bien nos besoins, combiné avec des scripts ant on arrive a faire ce qu'on veut.

Je ne vois pas pourquoi le choix d'eclipse d'avoir changer le numero de version a 3 alors que ce n'est qu'une 2.x 'nettoyée' va changer la donne, en tout cas j'espere que les gens seront plus intelligent que ca.

bref, ca serait bien d'etre un peu moins pro-eclipse dans le titre des news. restons objectifs on ne fait pas encore partie des journaux a scandales .

[Traroth2]

Envoyé par ValCapri

Oui, en effet, il serait cool que les développeurs Jenkins rejoigne le projet Hudson à partir de la version 3.0. Quitte à faire "2" versions, une version "non stable" releasé 1 à 2 semaines (genre de milestone comme pour Eclipse) et une stable releasé quand elle est prête.

Surtout que la guerre avec Oracle pour OpenOffice et Hudson n'ont plus beaucoup de sens, vu qu'ils ont été donné à des fondations (Apache et Eclipse). Ils seront bon de travailler sur une fusion, car ça me donne l'impression qu'il y a de l'énergie gâchée.

Le seul "hic" avec Oracle reste Solaris et MySQL qui n'ont plus vraiment le caractère Open Source qu'ils avaient avant. Je vois mal MariaDB, Percona et MySQL fusionnés.

OpenOffice est sous licence ASL 2.0 alors que LibreOffice est en LGPL. Une fusion est donc possible uniquement si Apache renonce à développer OpenOffice, puisque le code résultant ne pourra être que sous LGPL (en fait, comme OpenOffice était initialement sous LGPL, je me pose des questions sur la légalité du passage sous ASL. Tous les contributeurs étaient-ils d'accord ?).

Jenkins est sous licence MIT, donc il n'y a pas du tout le même genre de problème. On peut parfaitement intégrer du code sous licence MIT dans un logiciel sous EPL.

[Mickael_Istria]

Niveau soutien a Hudson, c'est quand meme assez faible: Oracle, un contributeur d'une boite de service danoise, et c'est a peu pres tout! http://www.eclipse.org/projects/proj...hnology.hudson

La plupart des autres grosses boites membres de la fondation Eclipse utllisent Jenkins plutot qu'Hudson, tout simplement parce que le projet continue a evoluer plus vite. Il y a CloudBees derriere Jenkins, et CloudBees commence a etre une pointure. Ils ont pleinement la meme capacite (voire plus) a maintenir Jenkins qu'Oracte a maintenir Hudson.

Jenkins s'est empare de toute la communaute, ce qui lui met beaucoup d'avance sur Hudson. De plus, il y a de tres tres grosses installations de Jenkins un peu partout dans le monde, et Hudson n'a a ma connaissance pas de telle use-case. On a moins de souci sur le Jenkins chez JBoss (avec son bon millier de jobs et sa cinquantaine de slaves sur tous les OS) que la Fondation Eclipse n'en a avec Hudson pour une centaine de job et 13 slaves...

La Fondation garde Hudson parce qu'il est dans la Fondation, et non pas parce qu'il est mieux que Jenkins.
Jenkins n'a vraiment aucun souci a se faire je pense.

[jmini]

Envoyé par eclesia

bref, ca serait bien d'etre un peu moins pro-eclipse dans le titre des news. restons objectifs on ne fait pas encore partie des journaux a scandales .

Entièrement d'accord avec toi... Je signale que le titre n'est pas de moi. J'avais mis quelque chose de plus factuel (et de moins polémique).

Envoyé par eclesia

Je ne vois pas pourquoi le choix d'eclipse d'avoir changer le numero de version a 3 alors que ce n'est qu'une 2.x 'nettoyée' va changer la donne, en tout cas j'espere que les gens seront plus intelligent que ca.

Pour moi le changement de numéro de version a du sens: la retro compatibilité a été cassé dans certain domaine, la documentation, le bugtracker ne sont plus au même endroit, la licence change...

Du point de vu utilisateur, il n'y a vraisemblablement pas grand-chose.

On se retrouve plutôt avec un problème de lisibilité:
=> Jenkins 2.x est à mon avis plus avancé sur certains points que Hudson 3.x.

Envoyé par Traroth2

Jenkins est sous licence MIT, donc il n'y a pas du tout le même genre de problème. On peut parfaitement intégrer du code sous licence MIT dans un logiciel sous EPL.

A mon avis l'incompatibilité vient plutôt de toutes les modifications qui ont été faites au cœur d'Hudson.

[Freem]

Envoyé par eclesia

bref, ca serait bien d'etre un peu moins pro-eclipse dans le titre des news. restons objectifs on ne fait pas encore partie des journaux a scandales .

Pas encore, en effet

[air-dex]

Si Jenkins à une communauté, et il me semble que c'est le cas, cette dernière adaptera les solutions de Hudson pour Jenkins ou trouvera des alternatives pour Jenkins. Pas de soucis de ce côté là.

[jmini]

Envoyé par air-dex

Si Jenkins à une communauté, et il me semble que c'est le cas, cette dernière adaptera les solutions de Hudson pour Jenkins ou trouvera des alternatives pour Jenkins. Pas de soucis de ce côté là.

C'est dans l'hypothèse ou Hudson reprend la main ou l'avantage de l'innovation sur Jenkins. Pas certain que ce soit le cas pour le moment...

[Traroth2]

Envoyé par jmini

A mon avis l'incompatibilité vient plutôt de toutes les modifications qui ont été faites au cœur d'Hudson.

Ah ça, c'est parfaitement possible...