Hallo Forumgemeinschaft,
nach dem Startschuss eines Projekts sind Begeisterung und Neugier auf hohem level und bald kommt die Frage, wie man am Besten die Zwischenergebnisse sichert.
Bei mir geht es gerade darum, eine (und mit den Erfahrungen der ersten dann eine Weitere) Linuxdistribution auf die Bedürfnisse der zukünftigen user anzupassen und daraus eine Art Masterkonfiguration zu erstellen, die alle gewünschten und keine unnötigen Elemente enthält und auf unterschiedlicher Hardware funktioniert.
Astreine Virtualisierung wird nicht möglich sein, das liegt einfach an den unterschiedlichen Arbeitsumgebungen, in denen die user sein werden.
Wie "mastert" man richtig?
Worin liegt das "Geheimnis" von Univention, Red Hat Enterprise, Suse Linux Enterprise und all denen, die solche Lösungen entwickelt haben?
Dass es nur gemeinschaftlich geht und im Sinne der GPL ist klar, und diese Voraussetzungen sind auch gegeben.
Was mir schon gelungen ist ist, eine aktuelle SuSE 12.3 zu installieren, zu aktualisieren, "abzuspecken" und mit einigen Programmen und zugehörigen skripts zu ergänzen und dies auf einen anderen Computer zu übertragen, alles mit kostenfreien und Bordmitteln.
Dabei existieren mittlerweile drei "Beta-masterimages" in Form von vdi-files. Aber schon die Kommunikation über die "changelogs" zwischen vier parallel damit experimentierenden Menschen führt zu ansatzweiser Verwirrung.
Als Koordinator muss ich da irgendwie gegensteuern, ggf. bremsen, akkurate und vollständige Dokumentation einfordern und ggf. überprüfen, Sackgassen rechtzeitig erkennen usw.
Die "to-do-list" wächst oben schneller als sie unten abgehakt werden kann.
Kennt ihr solche Phasen?
Sind sie normal oder sind sie Zeichen für "So geht's nicht weiter"?
Ich tendiere im Moment zu folgender Orientierung in der Projektgruppe (4 Menschen):
a) die letztlich zu erarbeitende vdi-Konfiguration wird allen im Unternehmen bereit gestellt, Voraussetzung ist lediglich die installierte VirtualBox, Datensicherung und Snapshots macht jede/r selbst, Support für das jeweilige Basissystem (Mac, Windows, Linux) gibt es in der Gemeinschaft nicht, sich damit auszukennen ist individuelle Verantwortung
b) eine "richtige" Installation wird parallel entwickelt und halbjährlich mit der vdi (soweit wie möglich) in Übereinstimmung gebracht, aller Support im Unternehmen gilt denen, die sich für Festinstallation entscheiden
c) die Integration beider Wege (=einheitliches Masterimage für VirtualBox und zukünftig anzuschaffende Laptops) wird vertagt
d) Alpha-Versionen und alle aus ihnen resultierenden todo's werden in der gemeinsamen roadmap ignoriert und nach 4 Wochen aus ihr gelöscht, wenn sie das Alpha-Stadium nicht verlassen haben (individuelle Verantwortung)
e) Beta-Versionen werden einmal monatlich für max. 1/2 h ausgewertet, bleiben aber in individueller Verantwortung
f) Release Candidates erfordern Funktionalität unter VirtualBox und mindestens zwei Computern, davon 1 Laptop
f1) die Arbeit an RC wird nur aufgenommen, wenn der Initiator mindestens einen Mitstreiter findet,
f2) ein RC kann nur sein, was für alle zukünftigen user eine Vereinfachung verspricht
f3) alle in der Gruppe nutzen nur den aktuellen RC zur Weiterarbeit.
f4) ggf. erforderlicher Rückgriff auf einen früheren RC ist für alle obligatorisch.
g) erst wenn wir vier selbst sicher so arbeiten werden weitere MitarbeiterInnen / InteressentInnen eingeladen.
Angenommen, ihr wolltet innerhalb von zwei Jahren ein ganzes non-Profit-Unternehmen auf Linux umstellen, ohne fertige Lösungen incl. Support kaufen zu müssen, könntet ihr zustimmen?
nach dem Startschuss eines Projekts sind Begeisterung und Neugier auf hohem level und bald kommt die Frage, wie man am Besten die Zwischenergebnisse sichert.
Bei mir geht es gerade darum, eine (und mit den Erfahrungen der ersten dann eine Weitere) Linuxdistribution auf die Bedürfnisse der zukünftigen user anzupassen und daraus eine Art Masterkonfiguration zu erstellen, die alle gewünschten und keine unnötigen Elemente enthält und auf unterschiedlicher Hardware funktioniert.
Astreine Virtualisierung wird nicht möglich sein, das liegt einfach an den unterschiedlichen Arbeitsumgebungen, in denen die user sein werden.
Wie "mastert" man richtig?
Worin liegt das "Geheimnis" von Univention, Red Hat Enterprise, Suse Linux Enterprise und all denen, die solche Lösungen entwickelt haben?
Dass es nur gemeinschaftlich geht und im Sinne der GPL ist klar, und diese Voraussetzungen sind auch gegeben.
Was mir schon gelungen ist ist, eine aktuelle SuSE 12.3 zu installieren, zu aktualisieren, "abzuspecken" und mit einigen Programmen und zugehörigen skripts zu ergänzen und dies auf einen anderen Computer zu übertragen, alles mit kostenfreien und Bordmitteln.
Dabei existieren mittlerweile drei "Beta-masterimages" in Form von vdi-files. Aber schon die Kommunikation über die "changelogs" zwischen vier parallel damit experimentierenden Menschen führt zu ansatzweiser Verwirrung.
Als Koordinator muss ich da irgendwie gegensteuern, ggf. bremsen, akkurate und vollständige Dokumentation einfordern und ggf. überprüfen, Sackgassen rechtzeitig erkennen usw.
Die "to-do-list" wächst oben schneller als sie unten abgehakt werden kann.
Kennt ihr solche Phasen?
Sind sie normal oder sind sie Zeichen für "So geht's nicht weiter"?
Ich tendiere im Moment zu folgender Orientierung in der Projektgruppe (4 Menschen):
a) die letztlich zu erarbeitende vdi-Konfiguration wird allen im Unternehmen bereit gestellt, Voraussetzung ist lediglich die installierte VirtualBox, Datensicherung und Snapshots macht jede/r selbst, Support für das jeweilige Basissystem (Mac, Windows, Linux) gibt es in der Gemeinschaft nicht, sich damit auszukennen ist individuelle Verantwortung
b) eine "richtige" Installation wird parallel entwickelt und halbjährlich mit der vdi (soweit wie möglich) in Übereinstimmung gebracht, aller Support im Unternehmen gilt denen, die sich für Festinstallation entscheiden
c) die Integration beider Wege (=einheitliches Masterimage für VirtualBox und zukünftig anzuschaffende Laptops) wird vertagt
d) Alpha-Versionen und alle aus ihnen resultierenden todo's werden in der gemeinsamen roadmap ignoriert und nach 4 Wochen aus ihr gelöscht, wenn sie das Alpha-Stadium nicht verlassen haben (individuelle Verantwortung)
e) Beta-Versionen werden einmal monatlich für max. 1/2 h ausgewertet, bleiben aber in individueller Verantwortung
f) Release Candidates erfordern Funktionalität unter VirtualBox und mindestens zwei Computern, davon 1 Laptop
f1) die Arbeit an RC wird nur aufgenommen, wenn der Initiator mindestens einen Mitstreiter findet,
f2) ein RC kann nur sein, was für alle zukünftigen user eine Vereinfachung verspricht
f3) alle in der Gruppe nutzen nur den aktuellen RC zur Weiterarbeit.
f4) ggf. erforderlicher Rückgriff auf einen früheren RC ist für alle obligatorisch.
g) erst wenn wir vier selbst sicher so arbeiten werden weitere MitarbeiterInnen / InteressentInnen eingeladen.
Angenommen, ihr wolltet innerhalb von zwei Jahren ein ganzes non-Profit-Unternehmen auf Linux umstellen, ohne fertige Lösungen incl. Support kaufen zu müssen, könntet ihr zustimmen?