Con la recente proposta di spostare Hudson alla Eclipse Foundation , vi è stata valutata la possibilità che questo porterà ad un incontro di Jenkins e Hudson, o anche se il codice può essere Concesso sotto licenza EPL.
C'è stato un sacco di rabbia da parte della comunità Jenkins (come visto sulla discussioni commenti ) che non sono stati coinvolti o inserite nel bando di trasferirsi a Hudson. E mentre diverse società hanno messo la loro approvazione al movimento, CloudBees non ha ancora fatto.
In realtà, la proposta di passare alla fondazione Eclipse è stato sulle carte prima della forcella è verificato e respinto come troppo pesante un processo. Mentre Jenkins è sempre stato sviluppato in modo rapido, modo iterativo, Oracle e Sonatype voluto portare rilasci regolare e la prevedibilità del processo (cosa che è poi avvenuto nella comunità Jenkins, in ogni caso).
InfoQ allungò la mano per CloudBees per il loro punto di vista sulla situazione, e ha ricevuto risposte da Hudson / Jenkins creatore Kohsuke Kawaguchi e CloudBees CEO di Sacha Labourey.
InfoQ : Quali sono i tuoi pensieri in movimento ha proposto alla fondazione Eclipse, insieme con il dominio e il marchio?
Kohsuke Kawaguchi : Siamo stati molto sorpresi. In un certo senso, vedo questo come una conferma del successo del progetto Jenkins, come ho detto nel mio blog . Quando il divorzio stava accadendo, questo è stato infatti uno dei temi più controversi, ed erano molto fermo che non possono trasferire il marchio a qualcun altro - da quando questo era in realtà la leva finanziaria che stavano usando per ottenere quello che volevano dalla comunità. Vorrei che hanno scelto di fare questo quando abbiamo parlato, ma come dici tu suppongo i nostri sforzi sono stati necessari per rendere Oracle sentire che questa transizione è necessario. Credo che Eclipse Foundation è una fondazione molto rispettabile che è noto per la neutralità venditore.
InfoQ : codice esistente è copyright di cittadini e alle imprese sotto licenza MIT. Anche se questo non esclude che il software è pubblicarono dai detentori del copyright, la (non-Oracle/Sonatype) Jenkins comunità possiede una quota equa delle recenti modifiche al codice che sono state fuse in Hudson. Questo corrispondono alla vostra comprensione?
Kohsuke Kawaguchi : Sì, questo corrisponde la mia comprensione.
InfoQ : Se la Eclipse Foundation allungò la mano per CloudBees con una richiesta di re-licenziamento sotto EPL al fine di spostare la base di codice Hudson alla Eclipse Foundation, vorrei che essere qualcosa che si sarebbe disposti ad aiutare o essere attivamente disinteressato a partecipare?
Sacha Labourey : CloudBees partecipa alla comunità di Jenkins, e siamo stati abbastanza aperto di sostenere qualsiasi direzione la comunità Jenkins vuole prendere. La licenza MIT è una licenza più aperta e meno corporativo-driven di Eclipse e che ci piace. L'abbiamo vista come più inclusiva e aperta, ma non hanno obiezioni reale a qualsiasi licenza open source.
InfoQ : La proposta è, nella sua forma attuale, un punto di partenza solo. E ' aperto per gli altri ad aderire e partecipare . È stato notato questa è fornitore pesante e comunità di luce in questa fase. C'è qualche interesse in entrambe le CloudBees o altri membri entrare come parti interessate?
Kohsuke Kawaguchi : La comunità Jenkins sta per avere un incontro il 11 maggio alle 18:00 UTC sulla IRC Jenkins Chat del canale, e magari dopo che sapremo dove la comunità si trova su questo tema. Ci sono naturalmente considerando tutte le opzioni, e CloudBees sarebbe stare dietro come la comunità Jenkins decide.
Per me personalmente, l'esperienza di "divorzio" è ancora vivo nella memoria e le ferite sono ancora fresche che mi sento po 'cauto. Molte cose vengono fatte in un progetto open-source attraverso le relazioni umane e si fida, ed è cosa difficile da ricostruire.
InfoQ : Come funziona il modello Eclipse confrontare con il modello che Jenkins è opera sotto in questo momento? Ci sono differenze specifiche (o addebiti) al modo in cui sono gestiti i progetti Eclipse in generale?
Kohsuke Kawaguchi : progetti Eclipse sono responsabili di progetto, PMC, e committer. Jenkins progetto ha una scheda di governance e committer. Ci sono alcune differenze tecniche, ma non credo ci sia un bel po 'di differenza nel modo in cui il progetto opera e la struttura di voto va.
Penso che una differenza chiave è la barra molto bassi per un committer nave nel progetto Jenkins. Storicamente, non abbiamo bisogno di persone di rimanere in giro se stessi e dimostrare prima di renderli committer, e che ci hanno aiutato a reclutare più sviluppatori e ottenere piccole modifiche nel codice. Abbiamo anche mantenuto gli sviluppatori di plugin vicino a noi, che ha agito come un imbuto per portare a sangue fresco per la comunità. Questa agilità è nel nostro DNA e hanno contribuito a rendere Hudson successo in primo luogo. Ecco perché la comunità Jenkins è organizzata in questo modo, a perpetuare ciò che ci ha fatto con successo, consentendo di governance bilanciata.
L'ultimo punto è probabile che sia uno dei punti controversi per la comunità Jenkins. La fondazione Eclipse ha linee guida legali su quando divenire un committer, e ci sono documenti firmati che deve avvenire prima di qualsiasi accesso a commettere la concessione, che può richiedere un paio di settimane per essere completato. Tuttavia, la proposta è quella di ospitare il nucleo Hudson a Eclipse, e lasciare plug-in per essere ospitati altrove (per esempio, a GitHub) così l'agilità riguarda solo il core runtime invece dei contribuenti plugin.
Un altro punto chiave è uno dei leader del progetto. Molti nella comunità Jenkins non sosterrebbero un movimento a meno che Kohsuke è stato il capo del progetto, ma dato che nessuno sta discutendo la questione sul forum del progetto, la possibilità non è sorto. Tuttavia, il processo di Eclipse assicura che i committer sono uguali nei diritti di voto committer, qualcosa che non è stato sentito nella pre-forcella problemi.
In definitiva, la comunità Jenkins Jenkins deciderà se farà parte della Eclipse Foundation, sia come incontro di progetti o come entità indipendente. Mentre Kohsuke e CloudBees sono suscettibili di influenzare pesantemente questa decisione, e la maggior parte dei punti originali blocco sono stati risolti, il livello di sfiducia e mancata corrispondenza impedenza processo può essere ancora un divario troppo grande per riunire.
Infine, se la comunità Jenkins decide di continuare come un progetto separato sotto il loro stesso processo, non è chiaro se Hudson sarà in grado di muoversi verso la EPL senza diritti consenso dei titolari dei diritti che non sono stati impiegati da un'organizzazione EPL al del tempo. Certamente la base di codice attuale ha unito alcuni tra i post-forcella codice nuovamente dentro la base di codice Hudson, quindi a meno che tali consenso copyright titolari di usare sotto la nuova licenza EPL allora potrebbe non essere possibile utilizzare tali contributi così com'è.
Se la comunità Jenkins è interessata a combinare con la proposta di Eclipse o no, gli utenti finali (e gli sviluppatori di plugin) sarebbe meglio servito da non avere due forchette da scegliere.
Aggiornamento : l' incontro all'utente Jenkins ha concluso oggi con la proposta di creare un wiki con una lista di condizioni che devono essere soddisfatte al fine di tornare insieme. Molti utenti hanno votato -1 in caso di principio di passare alla Eclipse Foundation, ma c'era qualche progresso in discussioni su cosa significherebbe se Jenkins dovesse passare a Eclipse o Apache. Tuttavia, non vi era dubbio se la comunità Jenkins vorrebbe lavorare con la comunità Hudson. Una decisione verrà presa in merito alla riunione successiva, il 24 maggio.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.