Hallo Hendrik,
der Workflow für Bugs / Features is wie folgt: Entweder (a) trägt einer ein
Ticket direkt bei uns ein, jemand fixt das Problem, und wir portieren das Thema
nach OpenJDK-JIRA (incl. angehängtem Patch) oder (b) es steht bereits in Ticket
in OpenJDK-JIRA, jemand möchte es uns zur Lösung vorschlagen und kopiert es in
unser System, dann fixt jemand das Problem und wir hängen den Patch in
OpenJDK-JIRA an. Im Prinzip ist der Workflow egal, da es schlicht keinen gibt
(und keinen Festlegungsbedarf), denn seitens Oracle gilt: Nur
OpenJDK-OCA-Signer mit OpenJDK-JIRA-account liefern patches ab, und zwar in dem
sie an OpenJDK-JIRA-Tickets angehängt werden. Es gibt faktisch keine
Sonderbehandlung für TeamFX (der Prozess ist bei OpenJDK beschrieben). Eine
Synchronisierung ist nicht notwendig. Die Tickets bei uns dienen *unserer*
Koordination. Die Tickets bei Oracle dienen *OpenJDK's* Koordination.
Die Statistik stelle ich Oracle auf Nachfrage zur Verfügung, wie kürzlich
bereits geschehen. Wer für einen Punkt voten will, den es bei Oracle gibt, aber
nicht bei uns, trägt ihn bei uns ein. Wer für einen Punkt voten will, den es
bei Oracle nicht gibt, trägt ihn *nur* bei uns ein. Da es in diesem Fall nur um
eine Statistik geht, ist es zunächst irrelevant, dass dieser Punkt bei Oracle
nicht existiert. Da bei uns jeder Tickets eintragen kann (sofern er sich einen
Account anlegt), kann jeder Voten und Bugs / Features eintragen. Wenn Oracle an
einem Bug / Feature interessiert ist, das nur bei uns steht, wird Oracle
sicherlich den Eintrag in ihr System übernehmen.
Um es nochmals wirklich absolut eindeutig und klar zu sagen: Oracle ändert
seinen Prozess nicht. Niemals. Auch nicht für uns. Egal wie wir das finden oder
wie unflexibel es ist. "Punkt." ;-)
Ich habe mir übrigens die letzten Tage intensiv die aktuellen Cloud-Dienste von
github und gitlab angeschaut und kann nicht bestätigen, dass github in irgend
einer Weiße "besser" ist. Was genau ist denn am *heutigen* Cloud-Service von
gitlab effektiv und objektiv betrachtet schlechter als bei gitlab? Wie gesagt,
ich kannte gitlab bis vor kurzem nicht, finde es aber inwzischen tatsächlich
besser als github, vor allem aufgrund des hervorragenden Service und der
superschnellen Nachrüstung der von mir gewünschten Features. Aber lass uns die
anderen auch mal was dazu sagen...! ;-)
-Markus
-----Original Message-----
From: teamfx-bounce@xxxxxxxxxxxxx [mailto:teamfx-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Hendrik Ebbers
Sent: Montag, 11. Januar 2016 18:24
To: teamfx@xxxxxxxxxxxxx
Subject: [teamfx] Re: [teamfx] [teamfx] Re: [teamfx] [teamfx] Re: [teamfx]
Zusammenarbeit mit OpenJFX - Es geht vorwärts!
Hi,
das mit den Duplizieren der Tickets war bei mir bisher noch nicht angekommen.
Daher hier meine Frage: Welche Tickets soll es denn im System geben? Wie soll
das ganze mit den Tickets von Oracle einigermaßen synchron gehalten werden? Ich
kann mir den Workflow grad nicht so wirklich vorstellen. Oder existiert das
ganze komplett parallel / losgelöst zu dem JFX Jira und wir legen nur Tickets
an die unserer Meinung nach interessant sind? In dem Fall könnten wir aber
wieder keine Aussage treffen was die Community wirklich will sondern nur eine
Aussage was die Community von unseren Vorschlägen / Tickets am tollsten finden.
Bzgl. Einspielen von Patches: Ja, das ist mir klar. Allerdings ist mom. der
Workflow, dass man einen Patch an eine Issue im JFX Jira hängt. Das ist extrem
unflexibel und im Normalfall muss das ganze ja einen Review Prozess
durchlaufen. Das Oracle nicht patches aus einem anderen System abholt ist mir
völlig klar. Allerdings denke ich, dass ein JavaFX Patch auf jeden Fall einer
größeren Review durch mehrere Leute (max 3?) unterzogen werden sollte. Selbst
wenn Oracle Mitarbeiter sich hier in keiner Form beteiligen benötigen wir
meiner Meinung nach einen guten Review-Prozess und dazu passende Tools. Und
hier ist GitHub meiner Meinung nach auch das beste Tool. Hierdurch ist es auch
deutlich wahrscheinlicher, dass sich andere Entwickler das ganze anschauen.
Aber gut, das ist meine Meinung. Bin mal gespannt, wie der Rest das so sieht :)
Gruß,
Hendrik
Am 11.01.2016 um 18:10 schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:
Hallo Hendrik,
zunächst mal vielen Dank für Deinen ausführlichen Kommentar! :-)
Leider gibt es mit Deinem Vorschlag ein paar unüberwindliche Probleme...:
* Oracle wird definitiv offiziell *nicht* auf Github mitarbeiten, keine
Patches von externen Systemen abholen, und sich nicht an Diskussionen auf
externen Systemen beteiligen. Es ist expliziter Wunsch von Oracle, dass wir
ein eigenes, externes System nutzen. Wir sollen für unsere Zwecke *nicht*
OpenJFX-JIRA benutzen.
* Die Existenz eines öffentlichen Voting- und Kommentarsystems ist explizites
*Ziel* der Systemsuche, da dies immer wieder Community-Member von Oracle
fordern, Oracle es aber defintiv nicht bieten wird, und sie uns daher um ein
solches System gebeten haben.
* Alle Patches MÜSSEN über einen OpenJDK-Mitglied, einem OCA-Signer mit
JIRA-Account, *manuell* (!) erfolgen, wegen der Nachvollziehbarkeit des OCA.
Oracle wird definitiv *keinen* technischen Zugriff auf Fremdsysteme
durchführen aus diesem Grund.
* Oracle gibt definitiv TeamFX-Mitgliedern *keinen* JIRA-Account, diesen
bekommen *nur* regelmäßige Contributor zu OpenJDK (Du und ich haben einen,
viele andere aber nicht; vor allem viele externe Programmierer nicht, die nur
mal kurz was fixen wollen). Es ist jedoch explizites Ziel der Systemsuche,
dass *alle* TeamFX-Mitglied als auch jeder, der einen kleinen Bug Fix etc.
beisteuern will, Zugriff auf das neue System hat. Insofern ist ein Voting /
Commenting in OpenJDK-JIRA definitiv *keine* Lösung. Wir *müssen* daher
Tickets duplizieren. Wir *dürfen keine Tags* im OpenJDK-JIRA setzen, das hat
uns Kevin explizit *untersagt*. Das einzige was uns Oracle zugesteht ist, um
es endgültig und klar zu sagen, nur ein *Link* (als Kommentar) in ein
externes System.
* Ich habe in den letzten Monaten immer mal wieder verschiedene Gruppen an
Usern nach ihrer Prio bzgl. JavaFX gefragt -u. a. als Umfrage hier in der
Mailingliste- und das Ergebnis war überraschenderweise *unterschiedlich*.
Daher gilt für mich: Das klarste Ergebnis, wohin JavaFX gehen soll, bekommen
wir *nur* über eine Pareto-Analyse über einen möglichst großen Bestand an
Votes. Explizit sehe ich es nicht so, dass *unsere* Meinung hier eindeutig
ist, da wir nur ein paar Leute sind. Da unser Ziel ist, Oracle diesbezügliche
klare Tendenzen zu liefern, *müssen* wir möglichst viele externe Voten lassen.
-Markus
-----Original Message-----
From: teamfx-bounce@xxxxxxxxxxxxx [mailto:teamfx-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Hendrik Ebbers
Sent: Montag, 11. Januar 2016 09:51
To: teamfx@xxxxxxxxxxxxx
Subject: [teamfx] Re: [teamfx] [teamfx] Re: [teamfx] Zusammenarbeit mit
OpenJFX - Es geht vorwärts!
Hi,
und genau hier sehe ich ein großes Problem. Ich kann Tom da voll und ganz
nachvollziehen aber wenn wir wirklich was beisteuern wollen, dann brauchen
wir einen sinnvollen Prozess durch den die Qualität von Änderungen überprüft
werden kann. Das ganze ist für mich deutlich wichtiger als z.B. ein
Voting-System für Tickets. Sind wir mal ehrlich: Wenn Leute an einer Issue
arbeiten wollen / werden, dann werden sie sicherlich eine nehmen die sie A)
verstehen, B) glauben umsetzten zu können und C) selbst auch für sinnvoll
erhalten. Da keiner von uns dafür bezahlt wird glaube ich nicht, dass sich
einer findet um die Bugs / Requests mit den meisten Votes zu bearbeiten. Aus
diesem Grund bin ich auch ganz klar für GitHub, da es meiner Meinung nach
einige Vorteile gegenüber BitBucket und GitLab bietet (hab mit allen 3 System
schon einiges gemacht):
- GitHub ist einfach der Platzhirsch und wenn ich zu einem Projekt die Source
suchen will dann starte ich logischerweise da. Wenn wir also wollen, dass die
Öffentlichkeit etwas von unseren Bemühungen mitbekommt, dann sollten wir auf
GitHub setzten.
- Der Mercurial Vorteil von Bitbucket existiert für mich nicht. Würde JFX auf
SVN entwickelt würde hier ja hoffentlich auch keiner auf die Idee kommen
einen Clone in nem SVN System aufzusetzen. Git ist aktuell das beste was es
gibt und auch ganz klar der aktuelle Standard. Daher sehe ich keinen Grund,
warum wir was anderes nehmen sollten
- Ich denke, dass die Review von Änderungen deutlich wichtiger ist als z.B.
ein Voting-System. In diesem Bereich ist GitHub gegenüber der genannten
Alternativen einfach ungeschlagen. Vor allem GitLab hat für mich bei großen
Änderungen in der Review bereits versagt, da es extrem langsam ist etc.
Durch Nutzung von GitHub hätten wir alle Source und vor allem Änderungen an
einer öffentlichen und zentralen stelle und könnten es ja vielleicht sogar
hinbekommen, dass Kevin oder Jonathan den Code direkt in GitHub reviewen.
Hier erwarte ich sicher nicht, dass die jetzt hergehen und alle unsere
Code-Änderungen analysieren. Sollten wir aber z.B. wirklich ein Bugfix für
eine bestimmte für Oracle interessante Issue hinbekommen dann kann ich mir
folgendes vorstellen: Wir schicken den Oracle Jungs den Link zu einem
Pull-Request und die können da dann direkt mal ein Blick auf den Code werfen
und möglicherweise Kommentare / Änderungswünsche anbringen bevor das ganze
als Patch in Jira hinterlegt wird. Hierdurch würde der Prozess deutlich
einfacher / agiler. Ich hab schon mehrmals Tickets im JFX Jira gesehen in
denen in den Ticketkommentaren über die Source eines Patches diskutiert wird.
Das ist meiner Meinung nach der absolut falsche Ansatz in einer Zeit in der
man direkt den Sourcecode innerhalb eines PullRequests kommentieren kann.
Sobald ein GitHub PullRequest von allen Seiten (TeamFX Mitglieder und im
Idealfall jemand von Oracle) abgesegnet ist, dann können wir einen Patch
bereit stellen. Und dieser muss dann eh ins Jira wandern und wird durch die
beschriebene Vorarbeit hoffentlich nicht da verhungern und einsam sterben.
Bzgl. Voting: Für mich ist es eh fragwürdig ob es einen Mehrwert hat, wenn
wir Tickets duplizieren. Egal was wir anpassen, es sollte ein Ticket dafür im
JFX Jira geben. Wär es nicht besser, wenn wir dann auch da voten. Sollten wir
als TeamFX ein solches Ticket umsetzten wollen dann könnte es im JFX-Jira
einfach mit einem passenden Tag versehen werden und in unserem GitHub Repo
wird dafür ein Branch erstellt. Sollte man dann trotzdem ein Voting-System
benötigen kann auch so etwas wie feathub (http://feathub.com) für interne
Zwecke genutzt werden. Dass einfach jeder externe bei uns voted finde ich eh
nicht sinnvoll, da diese Votes in das JFX Jira gehören. Votes sollten maximal
für uns intern genutzt werden. Aber auch hier bin ich wie bereits gesagt
nicht sicher was es bringt.
Gruß,
Hendrik
Am 11.01.2016 um 09:28 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
Hallo,
Ich kann nur sagen, dass ich und BestSolution *sicher* keinen Code von
3. in OpenJFX übernehmen werden. Ansonsten wäre ich persönlich für github.
Tom
On 26.12.15 14:25, Alexander Casall (Redacted sender alexander.casall
for DMARC) wrote:
Hi Markus,
Alles in allem klingt es gut. Es schadet sicher nicht, das Projekt erst
mal auf Bitbucket zu packen. Bitbucket ist glaube ich auch passender, da
es Mercurial unterstützt.
Ich habe das OCA unterzeichnet, bin jedoch vorsichtig, das Risiko zu
tragen, den Code von Dritten rechtlich vollhaftend ins OpenJDK zu
spielen. Mein Vorschlag ist, dass wir erst mal alles machen, wie du
beschrieben hast und mal sehen, wie es sich entwickelt.
Wenn du willst, kümmere ich mich die Tage drum, auf Bitbucket alles
vorzubereiten. Leider ist der Team-Name teamfx schon vergeben - ich habe
den Besitzer aber mal angeschrieben, ob er uns den ungenutzten Account
überlässt.
VG
Alex
On 26.12.2015, at 14:03, Markus KARG <markus@xxxxxxxxxxxxxxx
<mailto:markus@xxxxxxxxxxxxxxx>> wrote:
Hallo TeamFX,
zunächst einmal "Frohe Weihnachten!" :-)
*Als kleine Weihnachtsüberraschung hat Kevin meine Fragen beantwortet,
wodurch sich für die Community endlich die Möglichkeit ergibt, die
Mitarbeit an OpenJFX zu vereinfachen!*
/Hauptkritikpunkte seitens der Community waren ja u. a. bislang:/
* Bugs melden ist etwas kompliziert und langwierig und man erhält kein
sofortiges / vernünftiges Feedback.
* Voten und Kommentieren können nur noch OpenJDK-Mitglieder bzw. wer
ein Agreement mit Oracle unterzeichnet hat.
* Oracle nimmt Contributions nur zögerlich an, arbeitet selbst jedoch
nur an den eigenen Features.
Wir haben nun eine Lösung ausgearbeitet, mit der Oracle einverstanden
ist, die für uns machbar ist, und welche der Community mehr Mitwirkung
ermöglicht. Diese möchte ich Euch im folgenden gerne vorstellen.
Vorab etwas zu Oracle's Verhalten. Wie Kevin mir erklärt hat, ist es
den Juristen im Hause Oracle sehr, sehr, sehr wichtig, dass jede an
OpenJDK gespendete Codezeile (und somit auch von JavaFX) absolut frei
von Rechten dritter ist, und sie der GNU GPLv2 + Classpath Exception
unterliegt. Da die Rechtslage in jedem Land etwas unterschiedlich ist
bzw. wie im Falle USA vs Deutschland komplett verschieden, geht Oracle
auf Nummer Sicher und verlangt von jedem, der direkt Code an OpenJDK
beisteuert (egal ob Bug Fix, Patch, Feature, Tool, Doku, was auch
immer), die persönliche Unterschrift unter einem "Oracle Contributor
Agreement (OCA)" [http://www.oracle.com/technetwork/oca-405177.pdf].
Das ist den meisten, die nur kurz einen Tippfehler in der Doku oder
einen kleinen Bug fixen möchte, natürlich viel, viel zu umständlich!
Dies verstehen die Projektverantwortlichen bei Oracle zwar, können
daran jedoch nichts ändern. Diskussionen in Foren oder mit
Oracle-Mitarbeiter darüber sind absolut zwecklos und können somit
unterbleiben. Definitiv wird Oracle keinen Code in die Hand nehmen,
von dem nicht ein OCA-Signer schwört, dass er frei von Rechten dritter
ist und er der GPLv2 unterliegt. Punkt.
Einen weiteren Aspekt gelang es mir ebenso zu klären: Das unselige
Bug-Melde-System. Mark Reinhold hat auf der Devoxx zugegeben, dass die
aktuelle Bug-Melde-System (http://bugs.java.com/) etwas unhandlich
ist. Er hat daher gemeinsam mit Stuart Marks versprochen,
mittelfristig das System so zu ändern, dass man zumindest regelmäßiges
Feedback erhält, wie weit der Review gediehen ist, d. h. die
Zeitspanne zwischen Eintippen der Meldung und auftauchen in JIRA soll
kein schwarzes Loch mehr darstellen. Das ist ja schonmal was,
wenngleich er keinen verbindlichen Termin genannt hat und es eine
wirkliche Mitarbeit an OpenJDK auch nicht wirklich nennenswert
unterstützt. An JIRA wie es derzeit eingerichtet ist wird definitiv
nichts geändert, auch deshalb, weil Oracle nicht will, dass zig
tausend Leute an den Tickets sowas reinschreiben wir "ist alles Mist"
oder "Hallo ich war auch da". Wer in JIRA Schreibrechte möchte, hat
einen OCA zu unterzeichnen, sich in erhebliche Umfang an OpenJDK zu
beteiligen, und danach den JIRA-Zugriff zu beantworten. Auch hinter
diesem Satz könnt Ihr einen dicken Punkt machen.
Kevin und ich sind uns einig, dass dies für die bessere Beteiligung
der Community an JavaFX jedoch ein Hindernis darstellt und wir sind
uns über folgende Idee einig geworden: Wenn TeamFX ein externes System
(Ticketsystem, Repository, whatever) betreibt, dürfen
TeamFX-Mitglieder, die Schreibrechte im OpenJFX-JIRA haben (ich zum
Beispiel) Links in Richtung des TeamFX-Systems in das OpenJFX-JIRA in
das Kommentarfeld einstellen; Oracle wird diese Links nicht entfernen;
diese Personen (also ich zum Beispiel) dürfen auch Bugs und Features
direkt in der OpenJFX-JIRA eintragen sowie Voting-Ergebnisse und
gesammelte Kommentare. Kevin hat uns zugesagt, Bugmeldungen garantiert
umgehend zu reviewen (das hat auch in den letzten Wochen wirklich gut
geklappt), und Features mögen wir (bzw. ich) im einzelnen mit ihm
Diskutieren, vorzugsweise auf openjfx-dev. Ebenso will er wirklich
ernsthaft versuchen, von uns dort angefragt Code Reviews zeitnah
durchzuführen. Von der rechtlichen Seite ist es so, dass der
OCA-Signer, der die Eintragungen in OpenJFX vornimmt, persönlich
haftet, wenn er gegen den OCA verstößt. Im Umkehrzug ist es Oracle
egal, wenn der Code dann nicht wirklich von dieser Person stammt. D.
h. ein OCA-Signer darf sehr wohl unter seinem Namen Fremdcode (Bug
Fixes etc.) in das OpenJDK-Projekt einbringen. Na das ist doch mal was!
Abgesehen davon wurde übrigens Johan Vos (Gluon) diese Woche zum
Committer ernannt. Das ist für die Community ein echter Zugewinn, da
er als Nicht-Oracle-Contributer nun Code in OpenJDK aufnehmen kann!
Das heißt nicht, dass Johan alles entgegen nimmt was man ihm schickt
-sicherlich wird er es ausschließlich für Gluon nutzen- jedoch heißt
das, dass es nun (im engen Rahmen) auch ohne Oracle geht, Code in
OpenJDK einfließen zu lassen. Sicherlich macht es Sinn, dass ich in
den nächsten Wochen mal Kontakt mmit Johan aufnehme und ihm TeamFX
vorstelle… :-)
*Meine Idee ist nun folgende:*
* Wir nutzen ein öffentliches, kostenloses System wie z. B. JIRA,
Bitbucket, Github, Gitlab, oder sonst was, und erlauben
nicht-OCA-Signern die Eintragung von Bug Reports, Feature Requests,
Bug Fixes, Patches, Features etc. "auf dem kurzen Dienstweg" (d. h.
ohne schriftliches Agreement, schlicht per jur. sog. "konkludentem
Handeln" und Beachtung der AGB, welche besagen, dass der Eintragende
die GPLv2 beachtet und dafür haftet, dass seine Eintragung frei von
Rechten Dritter ist (nach deutschem Recht entsteht dadurch ein
verbindlicher Vertrag, jedoch eben implizit).
* Dort veröffentlichen wir einen Text, der klar und eindeutig aussagt,
dass alle Code-Spenden frei von Rechten dritter zu sein haben und
bereits die User-Registrierung als rechtlich verbindliche Garantie
diesbezüglich zu werten ist, d. h. wer Code einträgt haftet für diesen
Code, und erlaubt die Weitergabe per GPLv2 - unter anderem an OpenJFX.
* Wir können dort jedem erlauben zu voten und zu kommentieren.
* Themen, die wir (TeamFX) als wirklich ernsthaft und wichtig
identifizieren, verlinken wir gegenseitig mit dem OpenJFX-JIRA (also
ich oder jemand von Euch mit JIRA-Zugriff) und werden ggf. die
Kommunikation mit Oracle über JIRA oder openjfx-dev abwickeln. Es wäre
sinnvoll, wenn sich dazu in unserem System ein TeamFX-Mitglied als
Bearbeiter des Tickets einträgt und dies dann auch wirklich
eigenverantwortlich durchzieht.
* Sofern uns Code übergeben wird oder wir selbst Code schreiben, wird
der bei uns eingetragene Bearbeiter gegenüber Oracle als der einzige
Autor genannt (also nicht TeamFX und auch nicht der Originalautor).
Natürlich kann der Originalautor als Contributor in UNSEREM System
weiterhin erscheinen. Der OCA-Signer ist verantwortlich dafür, dass
diese Code frei von Rechten dritter ist und der GPLv2 unterliegt.
* Sofern wir die Zeit finden, können wir über unser System eigene
Contributions entwickeln und sie dann auf gleichem Wege an OpenJDK
spenden. Die Spende erfolgt daber immer über den OCA-Signer und nie
über TeamFX, da TeamFX keine eigene Rechtspersönlichkeit besitzt.
Ich denke, damit lässt sich ganz gut arbeiten, und Kevin wird auch
wirklich zu seinem Wort stehen und unseren Aufwand würdigen!
*Stellen sich zwei Fragen, um deren Beantwortung ich jeden einzelnen
von Euch bitten würde:*
/(a) Sollen wir das so machen oder habt Ihr eine bessere Idee?/
/ /
/(b) Wenn wir das so machen, welches System sollen wir nutzen und wer
außer mir hat einen JIRA-Account bei OpenJFX?/
Mein Wunschkandidat wäre zwar Github gewesen, das besitzt aber
keine Vorting-Möglichkeit und wird mittelfristig auch keine bekommen
laut Betreiber (habe gerade gefragt). JIRA oder Bitbucket wären
gangbare Alternativen. Gitlab kenne ich zu wenig und hat
(ferienbedingt) nicht auf meine Anfrage reagiert.
-Markus
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
