ich würde gerne mehr machen, habe aber ehrlich gesagt etwas Berührungsängste. Bin ich in der Lage einen ordentlichen Bugreport zu schreiben? Ist das ein Bug oder habe ich etwas vermurkst? Melde ich das Upstream oder Debian? Ich habe Fremdquellen eingebunden, kann ich das trotzdem melden, oder liegt der Fehler vielleicht daran? Hilfreich wäre, wenn ich IRL erfahrenere Linuxuser kennen würde, aber die die ich kenne sind Familie und noobs.
Es macht Sinn Fehler dorthin zu melden, wo du das Paket welches fehlerhaft ist her hast. Sprich an die Distribution oder an die entsprechende Fremdquelle.
Sollte der Fehler an einer Abhängigkeit liegen welche über eine Fremdquelle installiert wurde, wird man es dir sagen und ggf. die Unterstützung verweigern.
Einen Fehler Upstream zu melde macht dann Sinn, wenn die Version Upstream ebenfalls noch gepflegt wird oder du weißt, dass der Fehler in einer durch Upstream gepflegten Version ebenfalls auftritt.
Der Bugreport sollte eine möglichst genaue Beschreibung des Fehlers enthalten und wie dieser nachgestellt werden kann. Auch ist es sinnvoll die Schritte mit anzugeben die du zur Problemlösung bereits versucht hast und deren Ergebnis.
Berührungsängste musst du keine haben. Solltest du etwas falsch gemacht haben oder weitere Informationen nötig sein, wird man es dir sagen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 24. Jun 2016 um 18:47.
@1ras: „Einen Fehler Upstream zu melde macht dann Sinn, wenn die Version Upstream ebenfalls noch gepflegt wird oder du weißt, dass der Fehler in einer durch Upstream gepflegten Version ebenfalls auftritt.“ (sic)
Erst an die distro melden, meist erhält man dann weitere unterstützung. Je nachdem wird einem direkt geholfen, oder du wirst darum gebeten mehr infos zu liefern. (Oder du wechselst frustriert deine distro, ne ne durchhaltewillen hilft. Dein erster bugreport wird meist von schlechter Qualität sein. Nur nicht aufgeben und dir hilfe holen, fragen was du tun kannst um den bugreport nützlicher zu machen ...)
Wenn der maintainer oder die person die die bug triage macht oder der der bug zugewiesen wurde den bug dann auch nachvollziehen kann, entscheidet sich ob es ein packaging problem ist oder ob es upstream klemmt. Falls upstream wird normalerweise deine distro bei upstream den bug melden. Du kannst dann mit debug daten und tests bei bedarf weiterhelfen.
Normalerweise ist das ganz interessant und lehrreich. Ich habe als noob den weg in der betaphase eines distrorelease mitgemacht und es sehr gerne gemacht. leider fehlt mir momentan einfach die Zeit dazu
An die Distro melden? Hast du schonmal was bei Ubuntu gemeldet. Da kann man es gleich lassen. z.B. Kernel Bugs werden einfach wegignoriert und das Ticket geht automatisch nach einigen Monaten zu. Oder apt-btrfs-snapshot ist seit ueber einem Jahr defekt. Auf manchen Systemen funktionierts, auf anderen nicht. Da werden die Tickets zwar beachtet aber eine Loesung ist nicht in sicht. HIer ist schwer cherry-picking am start. Aber ich kenne auch communities da wird man ernst genommen und man befasst sich ernsthaft mit dem Problem, z.B IP-Fire.
Ansonsten (bzw. in erster Linie) an die Distribution bzw. an die entsprechende Fremdquelle, welche das Paket bereitgestellt hat.
Falls der Ausdruck Upstream zur Verwirrung geführt hat, damit ist das eigentliche Softwareprojekt gemeint, z.B. im Falle von LibreOffice wäre dies https://www.libreoffice.org/ oder im Falle von Firefox wäre dies https://www.mozilla.org/
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 25. Jun 2016 um 17:49.
Wenn der Bugreport unvollständig ist, dann wird die Nachfrage kommen was noch benötigt wird. Wahrscheinlich macht man das beim nächsten Mal dann schon besser.
Tendenziell würde ich Bugs immer direkt beim Entwickler melden, denn die kennen sich mit dem Sourcecode aus. Ein Bugreport beim Distributor kann man machen und ist auch manchmal hilfreich (z.B. wenn es ein distributionsspezifischer Bug ist).
Man sollte allerdings beachten, dass manche Entwickler darauf bestehen, dass die neueste Version der Software getestet wird, ggf. besteht der Bug ja gar nicht mehr. Da kann es dann je nach Distribution schon etwas komplizierter werden.
Immer Bugreports schreiben wenn Fehler entdeckt wurden. Selten Patches schreiben und an den Bugreport anhängen. Manchmal Dokumentation schreiben und Fehler darin berichtigen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 24. Jun 2016 um 16:13.
Wir brauchen mehr Leute die Doku schreiben, im speziellen Getting Startets. Ich habe nicht die Fähigkeiten ist eine Ausrede oder Selbstunterschätzung. Traut euch bei dem Open Source Projekt eures Vertrauens mitzuhelfen, im speziellen als Nicht-Entwickler.
bin ich der Hauptentwickler von Gnome Commander, einem Zwei-Spalten Dateimanager. Wie ich dazu gekommen bin und was es mir gebracht hat habe ich vor einiger Zeit hier aufgeschrieben (auf Englisch).
Alles in allem hat es mein Leben total bereichert und ich habe seit dieser Zeit wahnsinnig viel über Softwareentwicklung und Open Source Projektmanagement gelernt. Von daher kann ich nur jedem empfehlen, einfach mal irgendwo anzufangen. Hilfe, in welcher Form auch immer, ist bei jedem Projekt gerne gesehen!
Gute Arbeit - du brauchst hier nicht erklären, was der GNOME Commander ist - den kennt man
Klasse Tool, nutze ich sehr gerne! (Genau genommen jeden Tag, Privat wie auf der Arbeit) - Vielen Dank für die viele Arbeit!
Ich habe mir im Monat ein Budget von 20,00 EUR festgesetzt, was ich immer an Softwareprojekte Spende - teilweise aufgteilt, teilweise auch an einzelne - da ihr ja selber keine Spenden einsammelt, werde ich ein paar Mark für die FSF drauflegen - stellvertretend für euch
Ich bin (leider) weder Entwickler noch Programmierer und sehe mich - durch meinen eigenen beruflichen Werdegang und meine Erfahrungen - eher als Administrator. Und in diesen Sinne betreibe ich eine Linux Webseite, die sich mit verschiedenen Fragestellungen und Dokumentationen zu Linux beschäftigt. Das ist meine kleine 'Gabe' an die Welt der freien Software. Ich hoffe, dass zählt auch was...
Ich würde mich gerne an der Entwicklung beteiligen aber weiss nicht so richtig wie und wo ich einsteigen kann. Welches Projekt ist für den Einstieg das richtige, wo kann ich helfen? Gibt es eine Plattform auf der sich Projekte vorstellen bei denen ich auch als nicht-Profi einsteigen kann um meine Fähigkeiten zu verbessern und dabei trotzdem helfen kann. Gibt es ein Tutorial oder Leitfaden wie man vorgeht?
Von Michael Stehmann am Mo, 27. Juni 2016 um 12:17 #
Ein paar unmaßgebliche Tipps:
1. Nimm eine Software, die Du gerne und häufig nutzt. Dann ist Dein Interesse ein nachhaltiges.
2. Schätze Dein Talent ein und pflücke zunächst die niedrig hängenden Früchte. Beteilige Dich beispielsweise an der Lokalisierung des Programms in Deine Muttersprache. Da lernst Du gleichzeitig viel über die Bedienung des Programms und seine Funktionen.
3. Patches für Fehler sind immer willkommen. Dafür musst Du ein Programm suchen, dessen Programmiersprache Du einigermaßen beherrschst.
4. Du kannst Dich auch an der Portierung einer Software in eine neuere Version seiner Programmiersprache beteiligen (wo dies gerade ansteht), z.B. nach Python 3 oder hin zu einer neueren qt- oder gtk-Version.
5. Wenn Du ganz mutig bist, nimmst Du ein überschaubares, aber nützliches Programm, dessen Entwickler ein wenig die Lust an ihm verloren hat, und helfe bei der Weiterentwicklung. Gefahr: Am Ende hast Du das Programm am Hals .
6. Wenn Du paketieren willst: Es gibt bei den Distributionen Listen verwaister Pakete. Hier gilt grundsätzlich auch das zu 1. Gesagte. Erfahrenere Paketbetreuer werden Dir helfen.
7. Halte einfach die Augen auf und schaue, wo Deine Fähigkeiten hilfreich sein können! Besuche Community-Veranstaltungen und rede mit den Leuten!
8. Mache nichts aus reinem Pflichtgefühl, nur um einen Job zu bekommen oder nur um anerkannt zu werden! Spaß muss immer dabei sein!
ich würde gerne mehr machen, habe aber ehrlich gesagt etwas Berührungsängste. Bin ich in der Lage einen ordentlichen Bugreport zu schreiben? Ist das ein Bug oder habe ich etwas vermurkst? Melde ich das Upstream oder Debian? Ich habe Fremdquellen eingebunden, kann ich das trotzdem melden, oder liegt der Fehler vielleicht daran? Hilfreich wäre, wenn ich IRL erfahrenere Linuxuser kennen würde, aber die die ich kenne sind Familie und noobs.
Oh, und in der Umfrage-Liste fehlt noch "Spenden". Das ist ja durchaus auch eine "Beteiligung"...
Sorry, mein Fehler. Da steht ja was von "aktiver" Beteiligung...
Es macht Sinn Fehler dorthin zu melden, wo du das Paket welches fehlerhaft ist her hast. Sprich an die Distribution oder an die entsprechende Fremdquelle.
Sollte der Fehler an einer Abhängigkeit liegen welche über eine Fremdquelle installiert wurde, wird man es dir sagen und ggf. die Unterstützung verweigern.
Einen Fehler Upstream zu melde macht dann Sinn, wenn die Version Upstream ebenfalls noch gepflegt wird oder du weißt, dass der Fehler in einer durch Upstream gepflegten Version ebenfalls auftritt.
Der Bugreport sollte eine möglichst genaue Beschreibung des Fehlers enthalten und wie dieser nachgestellt werden kann. Auch ist es sinnvoll die Schritte mit anzugeben die du zur Problemlösung bereits versucht hast und deren Ergebnis.
Berührungsängste musst du keine haben. Solltest du etwas falsch gemacht haben oder weitere Informationen nötig sein, wird man es dir sagen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 24. Jun 2016 um 18:47.@1ras: „Einen Fehler Upstream zu melde macht dann Sinn, wenn die Version Upstream ebenfalls noch gepflegt wird oder du weißt, dass der Fehler in einer durch Upstream gepflegten Version ebenfalls auftritt.“ (sic)
Ansonsten Downstream?
Erst an die distro melden, meist erhält man dann weitere unterstützung.
Je nachdem wird einem direkt geholfen, oder du wirst darum gebeten mehr infos zu liefern.
(Oder du wechselst frustriert deine distro, ne ne durchhaltewillen hilft. Dein erster bugreport wird meist von schlechter Qualität sein. Nur nicht aufgeben und dir hilfe holen, fragen was du tun kannst um den bugreport nützlicher zu machen ...)
Wenn der maintainer oder die person die die bug triage macht oder der der bug zugewiesen wurde den bug dann auch nachvollziehen kann, entscheidet sich ob es ein packaging problem ist oder ob es upstream klemmt.
Falls upstream wird normalerweise deine distro bei upstream den bug melden. Du kannst dann mit debug daten und tests bei bedarf weiterhelfen.
Normalerweise ist das ganz interessant und lehrreich. Ich habe als noob den weg in der betaphase eines distrorelease mitgemacht und es sehr gerne gemacht. leider fehlt mir momentan einfach die Zeit dazu
An die Distro melden? Hast du schonmal was bei Ubuntu gemeldet. Da kann man es gleich lassen. z.B. Kernel Bugs werden einfach wegignoriert und das Ticket geht automatisch nach einigen Monaten zu. Oder apt-btrfs-snapshot ist seit ueber einem Jahr defekt. Auf manchen Systemen funktionierts, auf anderen nicht. Da werden die Tickets zwar beachtet aber eine Loesung ist nicht in sicht. HIer ist schwer cherry-picking am start.
Aber ich kenne auch communities da wird man ernst genommen und man befasst sich ernsthaft mit dem Problem, z.B IP-Fire.
Ansonsten (bzw. in erster Linie) an die Distribution bzw. an die entsprechende Fremdquelle, welche das Paket bereitgestellt hat.
Falls der Ausdruck Upstream zur Verwirrung geführt hat, damit ist das eigentliche Softwareprojekt gemeint, z.B. im Falle von LibreOffice wäre dies https://www.libreoffice.org/ oder im Falle von Firefox wäre dies https://www.mozilla.org/
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 25. Jun 2016 um 17:49.Mitmachen heißt ja im Endeffekt auch zu lernen.
Wenn der Bugreport unvollständig ist, dann wird die Nachfrage kommen was noch benötigt wird.
Wahrscheinlich macht man das beim nächsten Mal dann schon besser.
Tendenziell würde ich Bugs immer direkt beim Entwickler melden, denn die kennen sich mit dem Sourcecode aus.
Ein Bugreport beim Distributor kann man machen und ist auch manchmal hilfreich (z.B. wenn es ein distributionsspezifischer Bug ist).
Man sollte allerdings beachten, dass manche Entwickler darauf bestehen, dass die neueste Version der Software getestet wird, ggf. besteht der Bug ja gar nicht mehr.
Da kann es dann je nach Distribution schon etwas komplizierter werden.
Software frickeln, spenden und gelegentlich Übersetzungen.
Immer Bugreports schreiben wenn Fehler entdeckt wurden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 24. Jun 2016 um 16:13.Selten Patches schreiben und an den Bugreport anhängen.
Manchmal Dokumentation schreiben und Fehler darin berichtigen.
simpl4
Erstaunlich, was man bei sieben Teilnehmern alles in Prozent ausdrücken kann.
Update: Bild vergrößert: 40 Stimmen (unten rechts in der Ecke).
Wir brauchen mehr Leute die Doku schreiben, im speziellen Getting Startets. Ich habe nicht die Fähigkeiten ist eine Ausrede oder Selbstunterschätzung. Traut euch bei dem Open Source Projekt eures Vertrauens mitzuhelfen, im speziellen als Nicht-Entwickler.
... aber für mich sind die Entwickler und Unterstützer freier Software die wahren Helden des Alltags.
bin ich der Hauptentwickler von Gnome Commander, einem Zwei-Spalten Dateimanager. Wie ich dazu gekommen bin und was es mir gebracht hat habe ich vor einiger Zeit hier aufgeschrieben (auf Englisch).
Alles in allem hat es mein Leben total bereichert und ich habe seit dieser Zeit wahnsinnig viel über Softwareentwicklung und Open Source Projektmanagement gelernt. Von daher kann ich nur jedem empfehlen, einfach mal irgendwo anzufangen. Hilfe, in welcher Form auch immer, ist bei jedem Projekt gerne gesehen!
Gute Arbeit - du brauchst hier nicht erklären, was der GNOME Commander ist - den kennt man
Klasse Tool, nutze ich sehr gerne! (Genau genommen jeden Tag, Privat wie auf der Arbeit) - Vielen Dank für die viele Arbeit!
Ich habe mir im Monat ein Budget von 20,00 EUR festgesetzt, was ich immer an Softwareprojekte Spende - teilweise aufgteilt, teilweise auch an einzelne - da ihr ja selber keine Spenden einsammelt, werde ich ein paar Mark für die FSF drauflegen - stellvertretend für euch
Whuhuuu, vielen, vielen Dank!
Ich bin (leider) weder Entwickler noch Programmierer und sehe mich - durch meinen eigenen beruflichen Werdegang und meine Erfahrungen - eher als Administrator. Und in diesen Sinne betreibe ich eine Linux Webseite, die sich mit verschiedenen Fragestellungen und Dokumentationen zu Linux beschäftigt. Das ist meine kleine 'Gabe' an die Welt der freien Software. Ich hoffe, dass zählt auch was...
Ich würde mich gerne an der Entwicklung beteiligen aber weiss nicht so richtig wie und wo ich einsteigen kann.
Welches Projekt ist für den Einstieg das richtige, wo kann ich helfen?
Gibt es eine Plattform auf der sich Projekte vorstellen bei denen ich auch als nicht-Profi einsteigen kann um meine Fähigkeiten zu verbessern und dabei trotzdem helfen kann.
Gibt es ein Tutorial oder Leitfaden wie man vorgeht?
Ein paar unmaßgebliche Tipps:
1. Nimm eine Software, die Du gerne und häufig nutzt. Dann ist Dein Interesse ein nachhaltiges.
2. Schätze Dein Talent ein und pflücke zunächst die niedrig hängenden Früchte. Beteilige Dich beispielsweise an der Lokalisierung des Programms in Deine Muttersprache. Da lernst Du gleichzeitig viel über die Bedienung des Programms und seine Funktionen.
3. Patches für Fehler sind immer willkommen. Dafür musst Du ein Programm suchen, dessen Programmiersprache Du einigermaßen beherrschst.
4. Du kannst Dich auch an der Portierung einer Software in eine neuere Version seiner Programmiersprache beteiligen (wo dies gerade ansteht), z.B. nach Python 3 oder hin zu einer neueren qt- oder gtk-Version.
5. Wenn Du ganz mutig bist, nimmst Du ein überschaubares, aber nützliches Programm, dessen Entwickler ein wenig die Lust an ihm verloren hat, und helfe bei der Weiterentwicklung. Gefahr: Am Ende hast Du das Programm am Hals
.
6. Wenn Du paketieren willst: Es gibt bei den Distributionen Listen verwaister Pakete. Hier gilt grundsätzlich auch das zu 1. Gesagte. Erfahrenere Paketbetreuer werden Dir helfen.
7. Halte einfach die Augen auf und schaue, wo Deine Fähigkeiten hilfreich sein können! Besuche Community-Veranstaltungen und rede mit den Leuten!
8. Mache nichts aus reinem Pflichtgefühl, nur um einen Job zu bekommen oder nur um anerkannt zu werden! Spaß muss immer dabei sein!