.titleBar { margin-bottom: 5px!important; }

Freetz Roadmap Diskussion

Dieses Thema im Forum "Freetz" wurde erstellt von TIK, 14 Sep. 2011.

  1. TIK

    TIK Neuer User

    Registriert seit:
    14 März 2011
    Beiträge:
    64
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    #1 TIK, 14 Sep. 2011
    Zuletzt von einem Moderator bearbeitet: 15 Sep. 2011
    [edit olistudent]: Beitrag aus Bounty Thread abgetrennt


    ich gebe 50eur für eine vernünftige freetz-roadmap, damit solche sachen wie "ich zieh jetzt mal den neuen branch" der vergangenheut angehören...
     
  2. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,761
    Zustimmungen:
    5
    Punkte für Erfolge:
    38
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Ich verstehe nicht was du meinst? Freetz ist ein Projekt, dass wir alle in der Freizeit machen. Wie würdest du die Roadmap denn festlegen? Ich denke nicht, dass es sinnvoll ist feste Termine anzugeben. Erstens weiß man nicht, ob bis dahin ein bestimmtes Feature integriert ist und zweitens kann AVM immer mal mit neuer Firmware kommen. Ich überleg mir ja nicht, wenn ich aus dem Fenster schaue: "Oh heute sieht das Wetter nach Branch ziehen aus...". Aber auch reiffert hat schon Vorgeschlagen einen Projekt-Manager zu bestimmen.

    Gruß
    Oliver
     
  3. Joe82

    Joe82 Aktives Mitglied

    Registriert seit:
    22 März 2007
    Beiträge:
    1,113
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Lehrer
    Ort:
    Rinteln
    Hallo,
    zum Thema Roadmap hätte ich einen Vorschlag zu machen. Ich selbst bin nur Anwender und weiß nicht in wie weit das machbar ist, deshalb bitte nicht gleich in der Luft zerreißen.
    AVM hält mit den Firmwareupdates für die Top Boxen sehr genau einen halbjahres Rhythmus ein. Ich würde vorschlagen, dass immer nachdem die neu erschienene Firmware eingepflegt ist ein Branch gezogen wird. Dieser wird dann ein halbes Jahr stehen gelassen und Bug gefixt. Bei erscheinen der nächsten Firmware sollte dieser reif sein zur Stable zu werden.
    So könnte man sagen, Labortester sollen den Trunk nutzen. Nutzer der aktuellen Firmware, nutzen den gezogenen Branch, und Nutzer die die Stable nutzen wollen hängen immer genau eine Firmwareversion hinterher.
    Ich hoffe man kann mein Gescheibsel nachvollziehen.
    Das es natürlich bei einem Kernel wechsel wie bei der letzten Firmware länger dauern kann und das nicht immer so klappen wird ist auch klar. Aber ich finde die Überlegung an sich nicht schlecht.

    @ Oliver
    Bitte verschieb dies dahin, wo es am Sinnvollsten ist. Ich weiß nicht ob eine Diskussion über die Roadmap in diesem Tread Sinn macht, oder ob man lieber einen eigenen Tread dafür erstellen sollte.
     
  4. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,761
    Zustimmungen:
    5
    Punkte für Erfolge:
    38
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    @Joe82
    Da hast du natürlich Recht. Deshalb hab ich dem Thema gleich mal einen neuen Thread spendiert.

    Gruß
    Oliver
     
  5. Silent-Tears

    Silent-Tears IPPF-Promi

    Registriert seit:
    3 Aug. 2007
    Beiträge:
    7,456
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    BI
    Ich frage mich, wer die Zeit hat, verwaltungstechnisch Branches zu Pflegen, zu Mergen auf Zeit, etc?
     
  6. Joe82

    Joe82 Aktives Mitglied

    Registriert seit:
    22 März 2007
    Beiträge:
    1,113
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Lehrer
    Ort:
    Rinteln
    Hallo,

    wie viel Zeit beansprucht denn sowas? Ich bin eben vollkommen unwissend. Es wäre eben immer ein Trunk, ein Branch und eine Stable zu pflegen. Wobei doch die Stable an sich nicht soviel Arbeit macht oder sehe ich das falsch? Ich verstehe eben die Abläufe nicht und kann deshalb den Arbeitsaufwand nicht überblicken. Tut mir leid wenn mein Vorschlag vollkommen abwegig ist. Ich wollte auch nicht die Freizeit von anderen verplanen. Es war lediglich ein Vorschlag.

    LG
     
  7. Silent-Tears

    Silent-Tears IPPF-Promi

    Registriert seit:
    3 Aug. 2007
    Beiträge:
    7,456
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    BI
    Die Arbeit an sich ist nicht viel, aber nach der Idee oben muss man das alle halbe Jahre machen, und sehr regelmässig. Und diesw ist imho nicht machbar mit diesem Projekt, da dazu die Resourcen fehlen.
    nichts gegen häufigere Releases mit weniger Änderungen, wenn machbar, auch nichts gegen mehr Releases innerhalb eines Branches, aber Pflicht zur Regelmäßigkeit wird hart.
     
  8. TIK

    TIK Neuer User

    Registriert seit:
    14 März 2011
    Beiträge:
    64
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    wenn ich "roadmap" wortwörtlich übersetze und mir einen strassenatlas anschaue, kann ich dort keine zeiten finden. hier sind wege verzeichnet, wie ich von einem zwischenziel zum anderen zwischenziel komme bis ich letztendlich mein ziel erreicht habe. hier kann ich bei bedarf auch alternativrouten nehmen, wenn es die situation verlangt...
    das grundlegende dabei ist die reihenfolge: ich muss zuerst die strasse A befahren, um zur strasse B zu kommen um dann mein zwischenziel C zu erreichen. andersrum geht es einfach nicht...
    und bei einer roadmap für ein projekt werden erst im 2. schritt zeiten festgelegt. projektmanagmentsyteme erlauben mittlerweile sogar nicht mal mehr feste termine für meilensteine, sondern gehen davon aus, das es sich hier um eine zeitspanne handelt (was auch meist der realität entspricht). im fall von Freetz machen feste termine für meilensteine aus genanntem grund auch keinen sinn, darum geht es mir auch nicht.

    man kann heutige softwareprojekte nicht mehr mit projekten von vor 20 jahren vergleichen. die ansprüche der anweder sind ganz anders und die komplexität auch. es ist nicht mehr damit getan, die software zu erstellen. sie lebt weiter und muss gepflegt werden. mittlerweile beanspruchen pflege und wartung weit über 50% der gesamten entwicklungszeit.
    kontraproduktiv ist dann in einigen fällen auch noch die einstellung der entwickler. vorallem bei jüngeren leuten herrscht oftmals die einstellung: "wichtig ist doch erstmal das es funktioniert. schick mach ich das dann später..."
    in einem business-projekt hat man oftmals nicht die zeit, das dann zu realisieren. in einem opensource-projekt haben die leute dann oftmals keinen bock mehr, das zu realisieren und befassen sich dann lieber wieder mit neuen sachen.
    weiterhin erschwerend kommt hinzu, das anwender bzw. aussenstehende ein neues release nur anhand der neuen features messen. dies ist eine geisel der zeit. immer kürzere release-zyklen mit immer mehr unsinnigen features nur um den vergleich zur kokurrenz standhalten zu können. robustheit und stabilität ist heute kein verkaufsargument mehr...

    um jetzt den bogen wieder zu Freetz zu bekommen: gerade hier halte ich stabilität, robustheit und eine solide basis für weitaus wichtiger als tausende von paketen. in der roadmap vermisse ich den roten faden und vorallem feature freezes. es wäre wirklich schade, wenn man sich hier dem zeitgeist hingeben würde und sich auch nur noch an features orientiert. hier sollte man sich auch nicht dem druck der user im forum hingeben sondern ruhig und gewissenhaft die basis pflegen und wenn dann noch zeit ist, neue sachen zu integrieren...

    genau diesen weg haben wir seit einigen jahren eingeschlagen und laufen damit recht gut. da kommt bei einigen entwicklern nicht immer freude auf, wenn man neue ideen einfach mal so abschmettert. es landet damit auch nicht jeder mist sofort im CVS, erst wird ausgiebig getestet, dann eingecheckt. gerade bei verteilter entwicklung ist das gold wert. es muss sich nicht jeder mit den kinderkrankheiten rumschlagen. der trunk bekommt eine ganz andere qualität und entspricht zu über 90% bereits dem nächsten stable release.
    und wenn ich jetzt mal so die letzten 10 jahre zurückblicke konnte der zeitaufwand für pflege und wartung bei projekten und frameworkmodulen auf unter 5% gedrückt werden.

    und diese philosophie lebe ich seit über 20 jahren in der softwareentwicklung (davon 16 jahre im industriellen umfeld). ich würde mir wünschen, wenn sich davon was in der Freetz roadmap widerspiegeln würde, deshalb der kleine anreiz mit den 50eur.
    meine meinung muss hier keiner teilen, ich hoffe, sie ist jetzt ein wenig besser rübergekommen als nur der eine satz im ausgangsposting

    hmm, ich zitier hier jetzt mal nicht das posting zum 1.2er branch ;)
     
  9. TIK

    TIK Neuer User

    Registriert seit:
    14 März 2011
    Beiträge:
    64
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    aus eigener erfahrung: das ist nicht sinnvoll realisierbar, ohne massiv kapazitäten zu "verschwenden". die pflege und wartung frisst dich auf...