Firmware Aktualisierung

[Tim Niemeyer]

Am Sonntag, den 31.05.2015, 17:33 +0200 schrieb Steffen Pankratz:
> On Sun, 31 May 2015 15:45:49 +0200
> Tim Niemeyer <tim.niemeyer at mastersword.de> wrote:
> 
> Hi Tim
> 
> > Am Sonntag, den 31.05.2015, 15:15 +0200 schrieb Tobias Klaus:
> > > danke für deine Arbeit!
> > Auch von meiner Seite her danke.
> 
> Bitte :)
> 
> 
> > > Ich habe deinen Branch mal in meinem privaten Repo 
> > > adaptiert.
> > > 
> > > https://github.com/meskal/firmware/tree/CurrentOpenwrt [1]
> > > 
> > > Ich habe schon mal ein bisschen .configs gebaut und auch minimal getestet. 
> > > 
> > > Ich würde in nächster Zeit mal versuchen, die Patches ein bisschen zu 
> > > sortieren/aufräumen und dann in das Haupt-Repo einpflegen. Ich hoffe das ist 
> > > in deinem Sinne. Aktuell sind die für mich aber noch nicht so weit, deswegen 
> > > noch privat.
> > Bitte sprecht euch da ordentlich ab. Es wäre ungünstig wenn ihr am Ende
> > beide parallel an den Commits arbeitet. Vielleicht kann Steffen auch
> > seine Arbeit erst einmal in Ruhe fertig machen? Ich denke die eigenen
> > Arbeiten auf den Arbeitsbereichen anderer aufzubauen kann auch schnell
> > daneben gehen. (Du schreibst ja auch, dass man auf deinem Repo wegen
> > Rebases {Gut!} nicht aufbauen sollte.)
> 
> Mag sein, aber mit Git ist man so flexibel,
> was einmal committed wurde geht so schnell nicht verloren :)
> Aber gruendsaetzlich gebe ich Euch Recht in Sachen Arbeiten absprechen und
> keine 'private' Branches forken.
Ok, wenn ihr euch da einig seit, alles super. :-)

> 
> > > Was ich mich aber wundere, ist warum du in deinem repo Issues erstellt hast?
> > > Ich würde es begrüßen, die Entwicklung weiterhin zentral um das originale 
> > > Repository zu gestalten.
> > Dem schließe ich mich an. Weiter hätte ich aber den Wunsch solche
> > Diskussionen auf dieser Mailingliste zu führen. Von den Issues kriegt ja
> > ansonsten niemand was mit und wiederfinden tut man sie auch nicht. Ich
> > weiß auch nicht wie lange die dort archiviert werden.
> > 
> > > Bitte beachte auch, dass wir langfristig von diesem Repo weggehen werden und 
> > > eine neue Firmware hochziehen wollen. Wir arbeiten hier nach meinem aktuellen 
> > > Stand quasi "nur noch" an einem letzten stable Release.
> > Richtig, neue Features sollten wir nur noch im begrenzten Maß einbauen,
> > um den Test und Integrationsaufwand möglichst klein zu halten. Features
> > sollten also nur rein kommen, wenn sie die Netzstabilität erheblich
> > verbessern. Alle anderen Features sollten mMn direkt in die neue
> > Firmware kommen.
> 
> Um neue Features geht es mir gar nicht.
> Eher um Stabilitaet und Sicherheit des Status Quo.
> 
> 
> > > [1] Da ich ein Freund vom interaktiven rebasen bin und das Repo wirklich als 
> > > privat erachte, kann sich da schnell viel ändern und sollte nicht als stabil 
> > > angesehen werden.
> > Richtig. Für die Reviewer ist die Arbeit erheblich einfacher, wenn man
> > einige Dinge beachtet:
> > - Jeden Commit entsprechend kommentieren
> > - Commits zu logischen Sets zusammenfassen
> > - Jedes Set nochmal kommentieren
> > - Jedes Set sollte leicht verständlich und leicht zu reviewen sein
> > - Keine Reverts oder Merges mitten im Lesefluss
> > - Jedes Set an Änderungen sollte für sich allein stehen können und
> > sollte am besten auch für sich alleine angewendet werden können.
> > 
> > Richtig ordentlich wird das ganze, wenn man die erstellen Sets dann an
> > eine Mailingliste sendet. Ein super Tool dafür ist z.B. patman. patman
> > und generell eine gute Übersicht, wie das mit den Patches gut geht
> > findet man z.B. hier: http://www.denx.de/wiki/U-Boot/Patches
> 
> Viele der aktuelleren Commits wurde afaik nicht auf der Dev ML besprochen.
> Klingt mir persoenlich auch nach zu viel Overhead mit Patches an die ML,
> wenn man Github nutzt.
Das ist genau der Punkt. Das Repo liegt eigentlich nur da, weil der alte
Hoster geschlossen wurde. Im Moment ist das da bei GitHub nur ein Git
Repo. Der Workflow ist nicht der von GitHub.

Tobias und ich hatten bereits versucht für ffffnext das GitHub
Pull-Request Verfahren mit sauberen interactive rebases zu kombinieren.
Bisher ist uns das leider nicht gelungen, weil GitHub unsere Review
Anmerkungen gelöscht hat.

> Bei Github kann man Repos 'watchen' und kriegt alles mit was an Commits usw. passiert.
Das hat bei mir bisher nur mäßig funktioniert. Ich bin insgesamt sehr
unzufrieden mit GitHub.

> Die Historie geht bei Github auch nicht verloren.
Bei der Vorbereitung eines Änderungssets wird ja "git rebase -i"
verwendet. Dabei werden natürlich auch commits verschwinden.

> Das mag alles persoenliche Praeferenz sein.
> Fuer mich muss das Spass machen, ist ja auch Freizeit und nicht Arbeit :)
Richtig. Mir macht GitHub nur stress, es erleichtert meine
Arbeit/Freizeit nicht. :(

Tim

> 
> Gruss
> -Steffen
>