search

Freetz / freetz

Freetz firmware extension/modification for the ​AVM FRITZ!Box series and devices with identical hardware
https://freetz.org
GNU General Public License v2.0
300 stars 159 forks source link

Bug: unable to downgrade via Freetz GUI, ... #187

Open PeterPawn opened 5 years ago

PeterPawn commented 5 years ago

if a FRITZ!OS version is running, where the file /etc/version had get the latest changes (regarding the new way to store version values in /etc/init.d/rc.conf).

Only for the records, 'cause no-one else has mentioned it yet.

First analyses may be found here: https://www.ip-phone-forum.de/threads/openvpn-server-bridge-auf-7560-ipclient-fritz-os-7-01-freetz15014.302100/page-5#post-2328721

I'm personally unable to test any changes, I'm not using Freetz mod anywhere. Therefore I'm the wrong contact/consignee for further questions or tests, if anyone would start to solve the problem - sorry.

WileC commented 5 years ago

Ich bekomme bezüglich der /etc/version folgenden Fehler: May 29 11:27:05 fritz daemon.err dnsmasq[2874]: failed to update mtime on /etc/version: Read-only file system

PeterPawn commented 5 years ago

Das mag zwar auch mit der "/etc/version" zu tun haben, aber definitiv nichts mit dem Downgrade -> falsche Issue.

Ansonsten gehört das Thema (wenn man nichts Neues aufmachen will) hier hin: https://github.com/Freetz/freetz/issues/163 - weiter also dort.

er13 commented 5 years ago

Only for the records, 'cause no-one else has mentioned it yet.

Auch 4-Wochen-Frist oder darf es "for the records" auch länger offen bleiben?

PeterPawn commented 5 years ago

Gerne noch einmal deutlich ... wenn es (a) jemand zur Kenntnis nimmt (was hiermit vermutlich geschehen ist) und (b) es eine Perspektive für eine Lösung gibt, dann ist mir das egal.

Es ist nur nicht sinnvoll (die Gründe wiederhole ich nicht, auch andere Punkte aus den "best practices" sind so interessant/wichtig, daß man das schon selbst mal lesen sollte und dann kann man sich immer noch darüber austauschen, was davon auch für Freetz gelten sollte), solche Sachen ohne Reaktion stehen zu lassen.

Denkbare Reaktionen reichen von der Zuweisung von Labels (weil man bei einem Bug die Issues mit Tag "Enhancement" gar nicht erst ansehen muß) bis zur Zuweisung an einen Verantwortlichen - bei dem kann man dann nämlich auch mal nachfragen, ob/wann es weiter geht. Afaik ist das Zuweisen von Labels direkt beim Erstellen einer Issue nicht möglich (für den "Bearbeiter" weiß ich es sicher) - gegenteilige Infos nehme ich gerne und kennzeichne das dann auch selbst, wenn es funktionieren sollte.

Ich betone es gerne noch einmal: Diese Policy hat überhaupt nichts mit Dir zu tun - wer das tatsächlich verfolgt hat (und ich hatte meinerseits dorthin verlinkt: https://github.com/Freetz/freetz/pull/66#issuecomment-464047370 - ein "habe ich nicht mitbekommen" ist also auch keine nachvollziehbare Begründung), konnte auch kaum auf diese Idee kommen.

Denn der erste "Vorfall", bei dem ich das so gehandhabt und auch schon so begründet habe, liegt vom Datum her (15.02.2019) in einer Zeit, wo hier (und im IPPF) nur noch die ganz Unverdrossenen damit gerechnet haben, daß Du je wieder auftauchen würdest.

Als "Beweis" für diese "Erwartungshaltung" kannst Du gerne auch noch einmal in diesen PR schauen: https://github.com/Freetz/freetz/pull/116 - meine Aufforderung zur Diskussion (inkl. Verweis auf den Thread, wo wir unsere Positionen "ausgetauscht" haben - ich habe da nicht ein Argument versucht zu verschweigen) kannst Du dort im ersten Beitrag sehen.

Ich weiß jedenfalls nicht genau, was Dich jetzt wieder gebissen hatte (https://github.com/Freetz/freetz/pull/166#issuecomment-497272768), daß Du dieses für eine angemessene Reaktion hieltest ... aber ich bin inzwischen auch wieder auf dem Rückzug.

Ich werde in Zukunft wieder meinen Stiefel an meinem eigenen Fork durchziehen und auf PRs künftig verzichten. Sollte mal etwas dabei sein bei meinen (Freetz-)Branches und anderen Projekten, was irgendjemand für Freetz als "sinnvoll" erachtet, steht - sofern die Lizenz paßt, wenn das nicht von mir selbst schon in einem Freetz-Fork veröffentlicht wird - die Übernahme frei.

Aber meine Hoffnungen, daß es mit dem Übergang zu GitHub auch eine "neue Kultur" beim Umgang mit Vorschlägen von anderen geben könnte bzw. würde, habe ich inzwischen auch wieder begraben - und da meine ich auch nicht primär mich und meine Vorschläge (partiell schon, komme ich noch mal drauf zurück), damit das nicht wieder als "nu' isser beleidigt" fehlinterpretiert werden kann.

Es ist ganz einfach: Höflichkeit und Freundlichkeit tut normalerweise nicht weh ... schaut man sich so manches hier in diesem Repo an PRs und Issues an und die Reaktionen darauf, gewinnt man (zumindest geht es mir so, das MUSS man selbstverständlich nicht teilen als Ansicht) eher den Eindruck, daß solche "Ansinnen" eher dahingehend interpretiert werden, daß sie "die Friedhofsruhe", die ansonsten herrscht, stören, was in D obendrein strafbar ist (§ 168 StGB). Wobei das Zurechtschneiden der Hecken bei mir noch Bestandteil dieser Friedhofsruhe ist ... das läuft bei mir unter "Wartung" und "bloß nichts wirklich ändern/verbessern".

Wie es - bei der Freundlichkeit und beim Umgang mit den Leuten, die hier etwas beitragen wollen - besser ginge, zeigt(e) spaßigerweise schon @olistudent für den ersten PR, den jemand hier im GitHub eingebracht hatte: https://github.com/Freetz/freetz/pull/3#issuecomment-272713199

Danke für die Pakete.

Und nun behaupte bitte niemand, daß ein "Thanks!" nach einer "Aufgabenliste", die der "Störer" zunächst mal abzuarbeiten hat, dasselbe ist - das ist jedenfalls garantiert kein Dank dafür, daß sich da jemand beteiligen will.

Ich betone auch gerne noch einmal, daß es mir hier gar nicht um irgendwelche Threads geht, in denen sich @er13 und meine Wenigkeit direkt "beharkt" haben ... es ist der generelle Ton im Umgang mit anderen, der mir hier (sehr sauer) aufstößt und der mich - nach einer zwischenzeitlichen Phase der Hoffnung - inzwischen wieder zur Überzeugung gebracht hat, daß ich mich besser komplett ausklinke.

Ob das auch für Hilfen für Fragesteller im IPPF gilt oder nicht, habe ich noch nicht abschließend entschieden.

Sollte sich hier der Umgang miteinander (sichtbar) wandeln und dazu gehört es für mich auch, daß deutlich "selbstherrliche Entscheidungen" zurückgehen und zumindest ein Austausch (gerne auch zwischen den "members" - daß der im Sinne der Transparenz auch öffentlich sein sollte, steht wieder in den "best practices":

Don’t forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.

) stattfindet, würde ich das neu durchdenken ... aber so, wie er derzeit aussieht, ist mir der Umgang miteinander hier einfach zuwider. Punkt.

Wenn ich meinerseits hier zunächst mal irgendwie versucht habe, per E-Mail an die Vernunft und Einsicht von hier Beteiligten zu appellieren und für Änderungen zu argumentieren, dann geschah das nicht, um Transparenz zu verhindern, sondern um den Adressaten nicht direkt in der Öffentlichkeit vor den Kopf zu stoßen.

Transparenz und "Nachvollziehbarkeit" von Prozessen und was sonst noch so alles zu den "best practices" gehören würde (über einen Style-Guide für Beiträge anderer diskutiere ich mit @er13 seit 2014, weil dann dieses Aneignen fremden Codes um jeden Preis auch ein Ende haben würde, wenn sich der Autor an etwas orientieren kann) sind aber halt das, was ein OpenSource-Projekt auszeichnen sollte - zumindest dann, wenn "contributions" anderer tatsächlich erwünscht sind.

Dazu paßt aber der hier zu oft zu findende Anspruch des "Allwissens" und des "Allesselbermachens" (und selbstverständlich auch des "Allesbessermachens") nicht - was zwar abgenommen hat, aber immer noch viel zu deutlich vorherrscht und dieses auch noch, wo man doch eigentlich gar keine Zeit hat.

Diese Widersprüche und die daraus resultierenden Spannungen bleiben zu oft unerwähnt und die Argumentation, warum man das gar nicht anders handhaben könne bei diesem Projekt hier, wechselt da ja auch "nach Bedarf" - ein Pudding ist deutlich besser an die Wand zu nageln.

Schon die "Alleinherrschaft über den Code", die sich eben auch darin zeigt, daß hier jemand der Ansicht ist, er müsse/dürfe/solle immer direkt in den Master veröffentlichen und für ihn wäre es überflüssig, seine Änderungen zunächst mal in einem eigenen Fork bereitzustellen und von dort zu mergen (wer würde auch schon den Leichtsinn wagen, mit seinen Änderungen nicht einverstanden zu sein), ist für mich etwas, was (nicht länger) mit einem OSS-Projekt vereinbar ist.

Ich bin eigentlich zwischenzeitlich davon ausgegangen, daß sich hier - angesichts von "freetz-ng" und der Gefahr der Zersplitterung der Benutzerbasis und der Kräfte - tatsächlich etwas ändern würde - auch und gerade am Umgang miteinander und an der Arbeitsweise, die immerhin die Chance gehabt hätte, sich zu einer "collaboration" zu entwickeln.

Diese Erwartung sehe ich deutlich enttäuscht und da ich selbst ja - ich betone es noch einmal, weil es vielleicht auch meine fehlende Motivation erklärt, mich hier zum Löffel machen zu lassen - kein Freetz benutze und den eigenen Fork eigentlich nur für das "fulfillment" der Verpflichtungen aus der GPL für die von mir bereitgestellten Binärdateien brauche, kann ich gut damit leben, wenn ich mich in Zukunft deutlicher von Freetz abgrenze, ohne dabei gleich meinen eigenen Fork aufmachen und gezielt in eine andere Richtung als Freetz entwickeln zu müssen.

So, das hatte ja wieder mal nichts mit dem Thema der Issue zu tun und trotzdem war es mir ein Bedürfnis und ein Vergnügen, noch einmal "tabula rasa" zu machen vor dem Ausstieg - hier ist das auch so gut "versteckt", daß es nur wenige lesen und sich davon abschrecken lassen werden; denn das ist auch wieder nicht meine Intention, ich wünsche Freetz sogar viele neue Mitstreiter, wenn diese nur leidensfähig genug sind.

Um die Eingangsfrage auch noch zu beantworten:

Auch 4-Wochen-Frist oder darf es "for the records" auch länger offen bleiben?

Mach' was Du willst ... da ich künftig meinerseits für Freetz weder Issues noch PRs eröffnen oder mich innerhalb von ihnen äußern werde (das beschränke ich auf das IPPF und wenn sich der Fragesteller dort dann nicht selbst dazu entschließt, daraus einen Bug-Report bei Freetz zu machen, dann ist mir das künfitig auch egal), entfällt damit auch die Notwendigkeit, den "Fortschritt" dieser Aktionen zu überwachen oder zu kontrollieren. Damit ist es mir dann auch egal, wenn sich hier wieder ebenso ein Backlog aufstaut, wie er das schon im Trac-Server tat.

BTW ... warum war das meinerseits eigentlich nur "for the records"? Wer sich den Thread im IPPF ansieht (im ersten Beitrag verlinkt), der wird feststellen, daß ich zuerst mal den Freetz-Benutzer mit dem Problem aufgefordert hatte (denn mich kann das ja nicht selbst betreffen, wenn ich den Freetz-Mod gar nicht verwende), doch den Fehler einfach mal hier zu melden. Da er das nicht tat, habe ich mich tatsächlich "verpflichtet" gefühlt, hier noch darauf hinzuweisen ... heute kann ich das tatsächlich auch nicht mehr nachvollziehen, was mich da geritten haben mag.

Ich habe mit Stand heute jedenfalls alles das "abgearbeitet", wofür ich mich (zumindest moralisch) zuständig fühlte ... damit ist die Sache für mich gegessen und ich habe künftig keinen Bedarf mehr, einen eigenen Überblick (im Freetz-Projekt) über den Fortgang von Arbeiten an von mir eröffneten Issues oder Pull-Requests zu gewinnen.