Nur, wenn dich solche Entwickler-Themen interessieren, dann solltest du auch in der Lage sein, die MLs zu verfolgen - unter andrem deshalb, weil es bei vielen MLs Zusammenfassungen in wöchentlichem oder monatlichem Rythmus gibt -.
Ich persönlich glaube nicht, dass die Implementierungen schon weit entwickelt wurden, weil man mehr und öfter darüber hören würde, wenn sie "soweit" wären. In den letzten Monaten gab es nicht soviele Nachrichten über GNOME3.
Wenn man nicht unbedingt die Mailinglisten (z.B. desktop-devel-list oder gnome-shell-list) verfolgen möchte kann man auch die Blogs einiger Entwickler auf Planet GNOME im Feed-Reader abbonieren, die halt thematisch breiter gestreut sind.
Für GTK+ 3.0 fanden Entwicklungen für verschiedene Features (z.B. Multi-pointer support, resolution independence, extended layout, ...) bisher in verschiedenen Branches statt, die jetzt gereviewed und in den 2.90 Branch gemerged werden müssen.
Von Christopher Roy Bratusek am Fr, 23. Oktober 2009 um 13:12 #
>> gereviewed (...) gemerged
Also ich bin ja nicht anglophob, aber zumindest für eine Trennung von Deutsch und Englisch innerhalb eines Wortes, vor allem dann, wenn Denglisch überflüssig ist weil es bereits passende Deutsche Wörter gibt, oder das Wort auf andere (Schreib)Weise eingedeutscht wurde:
greviewed == reviewed || überprüft/begutachtet/bla je nach Kontext gemerged == merged || verbunden/verschmolzen/fusioniert/bla je nach Kontext
Einen ganz schlimmen Fall von Anglizismus durfte ich einmal hautnah erleben:
Einer Modeboutique war das englische Wort rucksack zu Deutsch, so dass sie body bag für das Aushangsschild der Wanderrucksäcke verwendeten.
Für alle die es nicht verstanden haben: body bag == Leichensack
Nichts gegen englische Wörter im deutschen Sprachgebrauch - mache ich auch tagtäglich - aber man muss ja nicht jeden Scheiß anglifizieren.
Von Christopher Roy Bratusek am Fr, 23. Oktober 2009 um 14:08 #
Wenn ich sage:
"Naja, eher sollte das Key Visual besser platziert werden, dann hat die Pre-Test-Kampagne einen höheren Benefit. Am besten mit einer In-House-Solution. Aber wenn es keine Geschwindigkeitsincreasements gibt und das der Kunde nach dem Re-Launch erfährt, sind wir unseren Key-Account los!"
dann verstehen es die meisten auch, aber ums Verständnis geht es überhaupt nicht. Ich hoffe das obige im Bezug auf einige Branchen *nicht* übertriebene Beispiel zeigt dir worum es mir eigentlich geht.
Wenn du in einem Marketing-Forum postset, dann ist das genau die richtige Wortwahl - vorausgesetzt das sind alles Marketing-Fachbegriffe (ich kenne mich in dem Feld nicht aus).
Das ist aber auch kein Fachbegriff. Mergen, branchen und reviewen nunmal Softwareentwickler-Fachbegriffe. Und der Physiker sagt auch "diffundieren" statt "verstreuen/ausbreiten".
Sagt der Physiker auch Sachen, wie: "Ich hab's gerade gediffundiert.", oder: "Diffundierst du bitte mal meine Zweifel, die aufgrund meiner Wortwahl meine Synapsen kontaminieren?"?
Nein, es interessiert mich gar nicht. Trotzdem möcht ich dir das irgendwie mitteilen. Was fällt sonst alles bei dir noch unter "sehr"? Ein anspruchsvoller Typ scheinst du nicht zu sein.
Was etwas verwirrt: Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder wird nur halb gebrochen? Kläre mich doch bitte einer auf.
Von Christopher Roy Bratusek am Fr, 23. Oktober 2009 um 13:18 #
Also ich finde "gebrochene Programmierschnittstelle" für "broken API" finde ich nicht so toll, gibt es - außer "inkompatible P..." nicht noch was eleganteres? Bei so vielen Wörtern in unserer Sprache MUSS es etwas geben.
Mit GNOME3 wird dir API-kompatibilität gebrochen. So wie es momentan aussieht wird die nächste GNOME Version zu 99% GNOME3 sein.
Man will GNOME aber nicht auf biegen und brechen veröffentlichen und ein KDE4 fiasko erleben. Deswegen hat man sich vorbehalten im Notfall noch ein GNOME 2.30 einzuschieben (welches dann die API-kompatibilität nicht bricht, da es noch eine Version aus der 2er Reihe wäre) und danach erst GNOME3 zu veröffentlichen.
Es wird also zu 99% kein GNOME2.30 geben. Sollte es wieder erwartetnd doch noch ein GNOME2.30 geben, dann gelten da natürlich die gleichen Regeln wie für jede Version der 2er Reihe.
Ich frage ja nur, weil man das doch jetzt wissen müsste: Bricht man mit der API oder nicht? Irgendwie müssen die richtigen Libs doch eingebunden werden und wenn ich das richtig verstanden habe, soll der Sprung auf GNOME 3.0 ja kein kleiner sein. Daher kann man wohl kaum ein fast fertiges GNOME 3.0 als 2.30 bezeichnen, da dann ja schon API-Brüche im System sein müssten.
Mit GNOME3: Ja Mit einem möglichen (wenn auch sehr unwahrscheinlichen) GNOME2.30: Nein
>Irgendwie müssen die richtigen Libs doch eingebunden werden und wenn ich das richtig verstanden habe, soll der Sprung auf GNOME 3.0 ja kein kleiner sein.
Klar müssen die libs irgendwann eingebunden werden. Ein GNOME2.X Programm, dass keine veralteten API Elemente verwendet wird aber problemlos auf GNOME3 übersetzbar sein. Man kann also selbst dann, wenn alle GNOME Programme "GNOME3-ready" sind immer noch entscheiden ob man ein GNOME2.X oder ein GNOME3 macht. Sollten nicht alle "GNOME3-ready" sein, dann wird man wohl den GNOME2.30 weg gehen müssen. Das ist aber wie gesagt sehr unwahrscheinlich.
> Sag mir doch lieber mal, ob mit 2.30 nun die API geändert wird oder nicht. Das müssen die Entwickler doch schon wissen oder?
So lange die vorderste Zahl gleich bleibt, bleibt die Plattform garantiert nicht nur API-, sondern sogar ABI-kompatibel. Sobald die Major-Version (die erste Zahl in der Versionsnummer) sich ändert, ist ein Bruch der Kompatibilität (API und ABI) erlaubt, und, im Falle von Gnome 3, auch angekündigt.
> Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht?
Offensichtlich noch nicht, sonst würde die Versionsnummer bereits feststehen.
> Kläre mich doch bitte einer auf.
In der Software Entwicklung gibt es verschiedene Entwicklungsmodelle. Zur Zeit sehr populär sind Modelle welche auf "agiler Softwareentwicklung" basieren. Dabei gibt es mehrere Verschiedene Modelle, welche zwar in Strukturen und Abläufen unterscheiden, jedoch auf den gleichen Grundprinzipien entwickelt werden: möglichst flexibel auf Änderungen von Anforderungen reagieren zu können.
Ich kenne mich zu wenig mit den Strukturen in der Gnome Entwicklung aus um den Namen für das verwendete Modell nennen zu können. Durchaus üblich bei solchen Prozessen ist aber, dass Features, Datum, Versionsnummer nicht fest aneinander gekoppelt sind. Bei Gnome wird offensichtlich das Datum als feste Größe verwendet: alle 6 Monate gibt es ein Release. Das erfordert dass Features nicht fest an die Releasenummern gebunden sind, müsste man u.U. unfertige Software veröffentlichen. Zusätzlich gibt es bei Gnome noch die Regelung das Major Versions-Nummern nur erhöht werden wenn Kompatibilität gebrochen wird.
Es wird also zu einem festgelegten freeze Termin die Entscheidung getroffen welche Features den Weg in die Version 2.28+1 finden werden. Dabei wird nicht entschieden was man gerne hätte (das wurde bereits vorher entschieden), sondern welche der zukünftig geplanten Features bereits weit genug um realistisch zum festgelegten Release Termin fertig zu werden. Je nachdem welche Features das sind, wird mit Kompatibilität gebrochen (-> 3.0) oder nicht (2.30).
Dieses Modell hat den Vorteil, dass man dabei Regelmäßige, absehbare Releases machen kann. Dabei kommt man aber nicht unter Zeitdruck was unfertiges zu veröffentlichen, oder Releses lange Zeit nach hinten hinaus zu schieben. Davon abhängenden Projekten (wie z.B. Distributions Releases) erleichtert das die Planung deutlich.
Genau das ist auch der Grund warum sich ein gewisser Mr. Shuttleworth so für feste Deadlines in der OSS-Entwicklung einsetzt. Leider scheinen noch immer viele Leute das Konzept dahinter verstanden zu haben, und meinen feste Deadlines für zu schlechteren, unfertigen Code.
>Was etwas verwirrt: >Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder >wird nur halb gebrochen? >Kläre mich doch bitte einer auf.
Es wird einige veränderungen in der gtk3 api geben welche zu gtk2 inkomaptibel sind, es ist aber weiterhin möglich verschiedene gtk versionen gleichzeitig zu installieren. Sollte gnome 2.30 erscheinen besitzt es noch gtk2. Ab 3.0 gtk3
Weitere Informationen findest du hier: http://www.gtk.org/plan/
Ich persönlich glaube nicht, dass die Implementierungen schon weit entwickelt wurden, weil man mehr und öfter darüber hören würde, wenn sie "soweit" wären.
In den letzten Monaten gab es nicht soviele Nachrichten über GNOME3.
GNOME Shell 2.28: Preview für das neue Desktop-Interface
Gnome 3 A Quick Visual Tour
Auch über den Boston Summit wurde berichtet.
GNOME Boston Summit 2009 Round-Up
Wenn man nicht unbedingt die Mailinglisten (z.B. desktop-devel-list oder gnome-shell-list) verfolgen möchte kann man auch die Blogs einiger Entwickler auf Planet GNOME im Feed-Reader abbonieren, die halt thematisch breiter gestreut sind.
Für GTK+ 3.0 fanden Entwicklungen für verschiedene Features (z.B. Multi-pointer support, resolution independence, extended layout, ...) bisher in verschiedenen Branches statt, die jetzt gereviewed und in den 2.90 Branch gemerged werden müssen.
GNOME Shell 2.28: Preview für das neue Desktop-Interface
Also ich bin ja nicht anglophob, aber zumindest für eine Trennung von Deutsch und Englisch innerhalb eines Wortes, vor allem dann, wenn Denglisch überflüssig ist weil es bereits passende Deutsche Wörter gibt, oder das Wort auf andere (Schreib)Weise eingedeutscht wurde:
greviewed == reviewed || überprüft/begutachtet/bla je nach Kontext
gemerged == merged || verbunden/verschmolzen/fusioniert/bla je nach Kontext
Einen ganz schlimmen Fall von Anglizismus durfte ich einmal hautnah erleben:
Einer Modeboutique war das englische Wort rucksack zu Deutsch, so dass sie body bag für das Aushangsschild der Wanderrucksäcke verwendeten.
Für alle die es nicht verstanden haben: body bag == Leichensack
Nichts gegen englische Wörter im deutschen Sprachgebrauch - mache ich auch tagtäglich - aber man muss ja nicht jeden Scheiß anglifizieren.
100% VOLLE ZUST
"Naja, eher sollte das Key Visual besser platziert werden, dann hat die Pre-Test-Kampagne einen höheren Benefit. Am besten mit einer In-House-Solution. Aber wenn es keine Geschwindigkeitsincreasements gibt und das der Kunde nach dem Re-Launch erfährt, sind wir unseren Key-Account los!"
dann verstehen es die meisten auch, aber ums Verständnis geht es überhaupt nicht. Ich hoffe das obige im Bezug auf einige Branchen *nicht* übertriebene Beispiel zeigt dir worum es mir eigentlich geht.
Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder wird nur halb gebrochen?
Kläre mich doch bitte einer auf.
Man will GNOME aber nicht auf biegen und brechen veröffentlichen und ein KDE4 fiasko erleben. Deswegen hat man sich vorbehalten im Notfall noch ein GNOME 2.30 einzuschieben (welches dann die API-kompatibilität nicht bricht, da es noch eine Version aus der 2er Reihe wäre) und danach erst GNOME3 zu veröffentlichen.
Es wird also zu 99% kein GNOME2.30 geben. Sollte es wieder erwartetnd doch noch ein GNOME2.30 geben, dann gelten da natürlich die gleichen Regeln wie für jede Version der 2er Reihe.
Mit GNOME3: Ja
Mit einem möglichen (wenn auch sehr unwahrscheinlichen) GNOME2.30: Nein
>Irgendwie müssen die richtigen Libs doch eingebunden werden und wenn ich das richtig verstanden habe, soll der Sprung auf GNOME 3.0 ja kein kleiner sein.
Klar müssen die libs irgendwann eingebunden werden. Ein GNOME2.X Programm, dass keine veralteten API Elemente verwendet wird aber problemlos auf GNOME3 übersetzbar sein. Man kann also selbst dann, wenn alle GNOME Programme "GNOME3-ready" sind immer noch entscheiden ob man ein GNOME2.X oder ein GNOME3 macht. Sollten nicht alle "GNOME3-ready" sein, dann wird man wohl den GNOME2.30 weg gehen müssen. Das ist aber wie gesagt sehr unwahrscheinlich.
So lange die vorderste Zahl gleich bleibt, bleibt die Plattform garantiert nicht nur API-, sondern sogar ABI-kompatibel. Sobald die Major-Version (die erste Zahl in der Versionsnummer) sich ändert, ist ein Bruch der Kompatibilität (API und ABI) erlaubt, und, im Falle von Gnome 3, auch angekündigt.
Also so wie bei KDE auch.
Offensichtlich noch nicht, sonst würde die Versionsnummer bereits feststehen.
> Kläre mich doch bitte einer auf.
In der Software Entwicklung gibt es verschiedene Entwicklungsmodelle. Zur Zeit sehr populär sind Modelle welche auf "agiler Softwareentwicklung" basieren. Dabei gibt es mehrere Verschiedene Modelle, welche zwar in Strukturen und Abläufen unterscheiden, jedoch auf den gleichen Grundprinzipien entwickelt werden: möglichst flexibel auf Änderungen von Anforderungen reagieren zu können.
Ich kenne mich zu wenig mit den Strukturen in der Gnome Entwicklung aus um den Namen für das verwendete Modell nennen zu können. Durchaus üblich bei solchen Prozessen ist aber, dass Features, Datum, Versionsnummer nicht fest aneinander gekoppelt sind. Bei Gnome wird offensichtlich das Datum als feste Größe verwendet: alle 6 Monate gibt es ein Release. Das erfordert dass Features nicht fest an die Releasenummern gebunden sind, müsste man u.U. unfertige Software veröffentlichen. Zusätzlich gibt es bei Gnome noch die Regelung das Major Versions-Nummern nur erhöht werden wenn Kompatibilität gebrochen wird.
Es wird also zu einem festgelegten freeze Termin die Entscheidung getroffen welche Features den Weg in die Version 2.28+1 finden werden. Dabei wird nicht entschieden was man gerne hätte (das wurde bereits vorher entschieden), sondern welche der zukünftig geplanten Features bereits weit genug um realistisch zum festgelegten Release Termin fertig zu werden. Je nachdem welche Features das sind, wird mit Kompatibilität gebrochen (-> 3.0) oder nicht (2.30).
Dieses Modell hat den Vorteil, dass man dabei Regelmäßige, absehbare Releases machen kann. Dabei kommt man aber nicht unter Zeitdruck was unfertiges zu veröffentlichen, oder Releses lange Zeit nach hinten hinaus zu schieben. Davon abhängenden Projekten (wie z.B. Distributions Releases) erleichtert das die Planung deutlich.
Genau das ist auch der Grund warum sich ein gewisser Mr. Shuttleworth so für feste Deadlines in der OSS-Entwicklung einsetzt. Leider scheinen noch immer viele Leute das Konzept dahinter verstanden zu haben, und meinen feste Deadlines für zu schlechteren, unfertigen Code.
Du meinst "nicht verstanden" zu haben und spielst auf GNOME an oder?
Nein, ganz im Gegenteil. Das sollte aber aus dem obigen Text hervorgegangen sein.
>Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder >wird nur halb gebrochen?
>Kläre mich doch bitte einer auf.
Es wird einige veränderungen in der gtk3 api geben welche zu gtk2 inkomaptibel sind, es ist aber weiterhin möglich verschiedene gtk versionen gleichzeitig zu installieren. Sollte gnome 2.30 erscheinen besitzt es noch gtk2. Ab 3.0 gtk3
Weitere Informationen findest du hier: http://www.gtk.org/plan/