DoorPI V3 / Planungen / Roadmap

  • Servus an die Gemeinde,


    als Neuling gleich einen solchen Beitrag eröffnen ist natürlich nicht die feine Art, aber ich muss positiv erwähnen, dass ich nach ein wenig Einarbeitung und dem Wälzen des Forums bisher noch keine Fragen hatte und mein Versuchsaufbau läuft bisher ohne Probleme. 8)


    Ich habe nun aber desöfteren gelesen, dass eine Version 3 erscheinen soll?!


    Bevor man sich nun an irgendwelche Bastelaktionen macht, wäre es interessant zu wissen, ob es eine Roadmap, möglicherweise sogar mit einer kleinen Timeline gibt.


    Hierzu habe ich leider sowohl im Forum, als auch bei Github nichts gefunden.

  • Das soll auch keine Kritik sein, und ich kann das sehr gut nachvollziehen.


    Ich denke, es ist einfach interessant zu wissen, wo es hingeht und ob er sich selbst Ziele gesetzt hat.


    Beispiel:
    Ich fange frisch an und habe Zeit für das Projekt. Wenn ich weiss, dass Feature X und Hardware Y zu Datum Z möglicherweise nativ unterstützt wird, warte ich gerne und integriere nicht irgendwas selbst gebasteltes in den raspberry.


    PS: Gibt es eigentlich nen Grund, wieso er das nach wie vor alleine macht? Github bringt doch den Vorteil mit, da gemeinsam zu entwickeln. Ich würde hier gern, sofern möglich, natürlich auch meine Hilfe beisteuern. Leider bin ich nur Softwareentwickler im Bereich PHP, HTML, SQL usw.
    Sofern also unterstützt für das backend benötigt wird, darf sich Thomas gerne melden. :)

  • Ich habe das auch nich als Kritk aufgefasst. Der Grund warum Thomas das alleine macht ist eigentlich der das zwar schon viele Hilfe angeboten hatten aber irgendwie daraus nichs geworden ist.
    Die Leute hier im Forum arbeiten teilweise ja mit und entwickeln hier scripte oder keyboards aber an der Basis arbeitet nur Thomas.


    Wir würden uns aber über jede weitere Hilfe freuen.


    Thomas aka motom001 ist aktuell in Urlaub bis zum 30.7. Du kannst ihn ja aber gerne mal anschreiben und Deine Hilfe anbieten.

  • Der richtige Weg ist im Moment, kleinere Sachen unter "Bugs/Probleme" einzustellen.


    Und nach dem Urlaub von Thomas sollte man in der Tat mal darüber reden, wer wie mitarbeiten kann.


    Tödlich für das Projekt wäre, wenn ein kompletter Umbau von DoorPi zu einer Version 3 stattfände, ohne dass alle derzeitigen Probleme gelöst sind.


    LG


    pah


    P.S.: Und, ja,


    Zitat

    als Neuling gleich einen solchen Beitrag eröffnen ist natürlich nicht die feine Art

    Dem stimme ich zu.

    • Offizieller Beitrag

    ob es eine Roadmap, möglicherweise sogar mit einer kleinen Timeline gibt

    das wäre schön, aber eine Roadmap bei einem open source Projekt mit nur einem aktiven Entwickler ergibt nicht viel Sinn.


    @pahenning hat an dem Punkt Recht: Eine Übernahme von alten Fehlern in eine neue Version ergibt nicht viel Sinn. Deshalb hatte ich mich zuletzt mehr darauf konzentriert, Bugs zu beheben, anstelle die neue Version voran zu bringen.


    darf sich Thomas gerne melden.

    Den Spieß würde ich gern zurück drehen - sofern irgendjemand Bugs erkennt und diese beheben will / kann, so bin ich gern bereit, diese in den master-Branch zu übernehmen. Die Änderungen können mir als Diff-Dateien, als txt-Dateien oder als PullRequest auf Github zur Verfügung gestellt werden. Das Projekt ist OpenSource und kann durch andere Entwickler auch gern vorangebracht werden. So vor kurzem durch @irgsmirx mit diesem PullRequest: "Adjusted a few minot things to make doorpi work with pjsua again"
    Das gilt natürlich auch, wenn jemand Erweiterungen schreiben möchte (wie z.B. von @pula ein keyboard). Es gibt bereits ca. 15% des Quellcodes, der nicht von mir stammt sondern von anderen mir zugespielt wurde - auf welchem Weg auch immer, darum kümmere ich mich im Bedarfsfall.

    Leider bin ich nur Softwareentwickler im Bereich PHP, HTML, SQL usw.

    Ich auch - DoorPi ist mein erstes Python-Projekt überhaupt. :P


    Der Quellcode wird für einen echten Python-Profi sicherlich schrecklich sein, da ein Großteil davon "historisch gewachsen" ist. Das war auch der Grundansatz für DoorPi 3, da dort auf Basis von UML-Diagrammen der Quellcode erzeugt wird und nicht aufgrund vom Quellcode die Diagramme. Aber so ist agile Entwicklung mit einer (großartigen) Community im Rücken wenn man das zum ersten Mal macht. Ich finde das persönlich nicht schlimm, denn von der ersten Version zum heutigen Stand ist viel passiert.


    Welches Feature in Zukunft wie angebunden werden kann ist zur Zeit nicht mehr als Wunschvorstellung. Wenn @pahenning die iButtons ins Spiel bringt oder Displays vorstellt, die angebunden werden können, dann werde ich mich als Entwickler garantiert nicht querstellen und ihm erst in 3-4 Monaten helfen um meine eigene Timeline einzuhalten. Priorität hat das, was aktuell gefragt ist.


    PS: Ich bin immer noch im Urlaub, hatte nur gerade Zeit, um das hier nicht unkommentiert stehen zu lassen.

  • Wenn's hilft: Vor 10 Jahren habe ich mit einem Kollegen das "Taschenbuch Programmiersprachen" und das "Handbuch Programmiersprachen" herausgegeben - mit kurzen und kompakten Beschreibungen von 26 Sprachen. Da das nicht mehr im Handel erhältlich ist, bin ich gerne bereit, ausgewählten Entwicklern(!) hier im Forum das entsprechende PDF oder EBook zur Verfügung zu stellen.


    Damit kann man sehr schnell Python lernen, wenn man beispielsweise PHP beherrscht.


    LG


    pah