PLANUNG

* Werbung machen
  Auf der Webseite, im Blog, etc.; ich würde auch den Menschen, der den
  Git-Vortrag macht mal fragen, ob er auf unseren Workshop hinweisen will.

# Gute idee, wobei der im Kernel Track stattfinden soll. Evtl ist das nicht
# unser Zielpublikum.
#
#   Das würde ich gar nicht mal so sagen - da gehen sicherlich auch mal
#   Hardware-Hacker hin, die ein bisschen git lernen wollen. Schaden
#   kann's nicht!

* Folien
  Wir werden hoffentlich zwei Beamer haben, können also mehrere Folien mit
  wichtigen Kommandos etc. vorbereiten, am besten per LaTeX-beamer oder so.
  (Ideensammlung bald, Umsetzung später. Dazu können wir gut die Datei
  git-workshop verwenden.)

# Es wird wichtig sein sich zu überlegen in welchen Reinfolge wir die Kommandos,
# und Konzepte vorstellen wollen. In meiner Erfahrung gibt es bei git immer das
# Henne-Ei Problem.
#
#   Ja, das lass uns morgen mal in Ruhe diskutieren. Ich würde mal als
#   grobe Roadmap aufstellen:
#       i) clone/init
#       ii) commit
#       iii) branches
#       iv) remotes (fetch, pull)
#       v) merge & rebase
#   Was meinst Du dazu?

# Ausserdem würde ich dir für solche folien evtl wiki2beamer an Herz legen.
# Evtl könnten wir mit ein bisschen Python aus dem wiki source code sowohl die
# Folien als auch den cheat sheet erzeugen? Meinem Informatiker Gehirn schein
# dieser Ansatz zu gefallen :-)))
#
#   Keine Ahnung... aber ich schau es mir heute mal an. :-)

* Workflow
  Was für einen Workflow wollen wir den Leuten vorstellen?
  Ich habe mir vorhin Gedanken gemacht und glaube, dass wir das "Pull from
  Me"-Prinzip vorstellen sollten, aus mehreren Gründen:

    i)   Es zeigt deutlich die Unterschiede zu herkömmlichen VCS auf.
    ii)  Es betont und führt in die *Verteiltheit* von git ein.
    iii) Mit diesem Ansatz arbeiten viele Projekte, so kann man schnell in die
         Entwicklung einsteigen (und dazu sollten wir die Leute ermutigen: Typo
         in der Manpage? -> Repo klonen, korrigieren, und Pull Request schicken!)
    iv)  Wir haben genau diese Situation: Ein Raum voller "Entwickler" und zwei
         "Project Leader", die darüber entscheiden, was rein kommt (und die das
         Master-Repo verwalten).

# Wollen wir trotzdem die anderen beiden workflows vorstellen, also 1-repo und
# email-patches? Damit machen wir das Publikum darauf aufmerksam das git bei der
# Gestaltung des workflow viele Freiheiten lässt, und sie sich aussuchen können
# wie sie gerne arbeiten möchten. 
#
#   Ja, definitiv! Ich glaube aber, dass, wenn man an einem Projekt
#   ein bisschen mitarbeiten will, man mit diesem Workflow am
#   schnellsten weiter kommt. Aber wir sollten definitiv die anderen
#   beiden Workflows vorstellen!

# Ein Problem könnte sein, das bei diesem workflow, die Teilnehmer relativ viele
# remotes hinzufügen müssten. Evtl, könnten wir auch ein Skript anbieten was das
# automatisiert, je nach dem wie unsere Infrastruktur am Ende aussieht.
#
#   Jein - wir müssten jeden Contributor als Remote hinzufügen, aber
#   die Leute eigentlich nur uns. (Oder ggf. die Leute neben ihnen
#   wenn die was zusammen machen.) Also liegt die Arbeit nur ein wenig
#   bei uns.

* Infrastruktur überlegen
  Sofern wir obigen Workflow praktizieren, habe ich mir folgendes überlegt:
  Wir lassen die Leute Namensschilder aufstellen vor sich (oder auf dem
  Monitor) mit ihrem Vornamen und haben einen zentralen Server (grml-Kiste?)
  auf dem wir den Leuten alle einen Account geben.
  Und dann könnte man statt einer Mailingliste einfach das so machen, dass man
  sagt, "so, jetzt ist zehn Minuten Zeit zum was entwickeln", und wenn jemand
  was fertig gemacht hat, dann kommt ein verbaler Pull-Request, und wir fetchen
  das live auf dem Beamer und wenn es keine Konflikte gibt, wird es direkt in
  den Master gemergt. Ich stelle mir das so vor:

    Bernd: "Ich habe mal ein paar Zeilen zu `git stash' geschrieben. Pull, please!"
    Wir: "Oh, cool, danke. Wo denn?"
    Bernd: "bernd/git-stash"
    Wir: >klacker<  git fetch bernd/git-stash
                    git diff ..FETCH_HEAD
                    git merge remotes/bernd/git-stash
                      fail: "Bernd, bring mal den Konflikt in Ordnung" -> git reset --hard
    Wir: "Dankeschön, Bernd!"

# Das klingt prinzipiell schonmal nicht schlecht. Ich bin mir aber noch nicht im
# Klaren wie die konfiguration konkret aussehen soll.

# Bei einer grml Kiste ist das Problem, das es sich hier um ein live System
# handelt und es beim Neustart nackt ist. Ausser wir basteln uns da was, z.B. ne
# custom grml wo alle unsere User und ihre repositories bereits angelegt wurden.
# Das wäre ziemlich cool! Da würde auch nen Absturz überleben, Kiste neu
# gestartet, einmal pushen, fertig!
#
#   Ich kann meinen Zweit-Laptop mit anderer Platte mitbringen, dann
#   können wir da ein frisches System drauf installieren. (Kann ich
#   auch noch zu Hause machen.)

# Eine möglichkeit wäre sicherlich mit gitosis zu arbeiten. Kennst du das? Damit
# könnten wir einfach drum bitten, das die Teilnehmer uns nen ssh-key
# zuschicken, oder aber ssh-keys für die Teilnehmer generieren, und diese
# verschicken. Wenn du es noch nicht kennst schau dir das mal an, das ist
# ziemlich cool. Oder hattest du vor das alle gleichzeitig auf einer Kiste
# arbeiten, und gegenseitig pullen? Habe ich das missverstanden? Ich denke ein
# Diagram wäre nicht schlecht. 
#
#   Lass uns auch das morgen im Detail besprechen, aber ich schaue mir
#   gitosis an. Können wir ja auf der Kiste installieren.

# Was für eine Kiste wollen wir da nehmen? Meinst du wir können uns vor Ort
# was geben lassen? Sollen wir die registrieren lassen und beim DNS anmelden?
# Dann müssten die Teilnehmer nicht mit IPs rumhantieren. 
#
# clone bernd@git-workshop/repos/bernd
#
#   Gute Idee; sollten wir aber lieber privat organisieren, "less
#   hustle". Wir können uns um eine Fixip kümmern und dann nen eigenen
#   DNS-Eintrag auf diesen Rechner erstellen.


# Ich denke das Thema 'setup vor Ort' braucht noch am meisten Überlegung und
# Arbeit. 

* Default Config
  Wir sollten ein wenig Config-Zeug vorbereiten. Wir können das auf der Folie
  hinschreiben mit git config user.email etc., sollten den Leuten aber auch
  eine vorgefertigte Textdatei mit wichtigen Config-Kommandos geben, die sie
  einfach in eine Shell pasten können.
  Zusätzlich wäre natürlich ein bisschen Shell-Scripting gut, um ein bisschen
  branch-info im Prompt oder so anzuzeigen für Bash und Zsh. Das ist aber eher
  nachrangig wichtig.

# Cheat sheet in text form ist auf jeden Fall super. Wir sollte drauf achten das
# es nicht zuviel Information enthält, aber trotzdem alle essentiellen Kommandos
# auflistet. 
#
#   Es gibt ja auch schon genug Beispiele online, denke ich mal.