Repository + Bugtracker + Dokumentation (Hardware + Software)
-
Hallo.
Betreibt hier zufällig jemand für sich privat zu Hause oder für eine kleinere Gruppe ein eigenes Coderepository mit Bugtracker und Dokumentationsmöglichkeit?
Das ganze wäre für mich eher eine spielerei.
Auf einem Raspberry Pi 2 würde wohl zB trac (http://trac.edgewall.org/) laufen. dann könnte man auf dem Pi sicher auch noch ein Git installieren und somit dürfte man das eigentlich fast haben. Für trac selbst braucht man dann halt noch eine Datenbank usw.
Hat damit eventuell jemand Erfahrung und könnte mir ein paar Empfehlungen oder Ratschläge geben? Idealerweise sogar mit Tutorial o.ä.
Man findet da durchaus genug brauchbares im Netz. Problem für mich ist häufig nur zu verstehen, ob das wirklich alles funktioniert oder nur theoretisch funktionieren müsste. Gerade bei sowas wie dem Raspberry Pi habe ich teilweise schon das gefühl, das er eigentlich alles können soll, aber irgendwie garnicht kann (leistungstechnisch).
Also am Ende will ich das ganze schon praktisch nutzen, auch wenn es nur eine spielerei ist!Mir ist klar, dass es für so etwas eigentlich GitHub, Google Code oder SourceForge gibt. Hätte das aber gerne bei mir lokal unter meiner Kontrolle etc pp.
-
Trac ist zwar ein hervorragender Bugtracker, aber auch ziemlich resourcenintensiv, vor allem, wenn man die Git-Integration verwendet.
-
Ich verwende eine Redmine- und eine GitLab-Instanz. Haben beide ihre vor- und Nachteile. Redmine ist Trac recht ähnlich, kommt mir persönlich aber moderner und schneller vor als ich Trac in Erinnerung habe. GitLab ist ein GitHub-Clone, der aber etwas mühsam zu deployen ist.
Privat verwende ich einfach eine Gitolite-Instanz. Gibt ein paar verteilte Bugtracker, die ich für meine privaten Projekte aber bis dato nicht verwende; dort reicht meistens ein Org-Mode-File oä. Mittelfristig hoffe ich, dass sich sowas wie bugseverywhere oder ditz sich genug stabilisiert, dass es auch für mittelmäßig interessierte Pragmatiker eine gute Wahl wird – nicht nur für Distributed-Bugtracking-Nerds.
-
Das trac resourcenintensiv sein soll wundert mich jetzt etwas. Dachte eigentlich das läuft u.a. auf einem Raspberry Pi, somit sollte das doch ressourcenschonender sein?
So etwas wie Bugseverywhere oder ditz kannte ich noch garnicht! Bin mir da jetzt aber nicht sicher, ob ich vertsehe was man damit alles machen kann und was nicht
Aber danke für die Antworten, jetzt hab ich erstmal wieder was zum lesen.
Wie macht ihr das eigentlich hardwaretechnisch. Habt ihr da zuhause im privaten Bereich eigene Hardware oder macht ihr das alles auf eurem Rechner und habt keine zusätzliche Hardware? Irgendwie ist zusätzliche Hardware dafür eigentlich überflüssig, aber eine nette spielerei wäre es schon.
-
repository schrieb:
Das trac resourcenintensiv sein soll wundert mich jetzt etwas. Dachte eigentlich das läuft u.a. auf einem Raspberry Pi, somit sollte das doch ressourcenschonender sein?
Vieles läuft auf dem Raspberry Pi. Vieles davon aber nur sehr sehr langsam.
So etwas wie Bugseverywhere oder ditz kannte ich noch garnicht! Bin mir da jetzt aber nicht sicher, ob ich vertsehe was man damit alles machen kann und was nicht
Im wesentlichen hältst du damit deine Bug-Datenbank direkt in Git (rein textbasiert) und bekommst ein hübsches Command-Line-Interface dafür.
Ich kann dir nichts darüber sagen, wie gut und bequem das in der Praxis funktioniert, aber das Konzept gefällt mir recht gut.
-
nman schrieb:
GitLab ist ein GitHub-Clone, der aber etwas mühsam zu deployen ist.
Mühsam zu deployen? Die letzten Updates nicht mitbekommen? Die haben inzwischen ein eigenes Repository:
https://about.gitlab.com/downloads/Notfalls geht es auch über Docker:
https://hub.docker.com/r/gitlab/gitlab-ce/GitLab wird bei mir immer mehr zum absoluten Hit. Git Repository, Issue Tracker, Wiki alles integriert. Äusserst einfach zu deployen. Inzwischen haben sie auch angefangen alle Settings über eine Admin-Page anzubieten. Einfach nur der Hit.
Übrigens, GitLab bietet auch ein direktes Repository für Raspberry Pi, wodurch grundsätzlich dann ein "sudo apt-get install gitlab-ce" reicht. Aber die Leute hinter GitLab warnen, dass es wahrscheinlich recht langsam laufe. Wahrscheinlich ist es in dieser Konfiguration höchstens für eine Einzelperson gedacht.
repository schrieb:
Wie macht ihr das eigentlich hardwaretechnisch. Habt ihr da zuhause im privaten Bereich eigene Hardware oder macht ihr das alles auf eurem Rechner und habt keine zusätzliche Hardware? Irgendwie ist zusätzliche Hardware dafür eigentlich überflüssig, aber eine nette spielerei wäre es schon.
Ich verwende derzeit virtuelle Maschinen, welche auf einem USB-Stick abgelegt sind. Aktuell überlege ich mir allerdings einen kleinen Server bei mir aufzusetzen. Entweder dann über eine DDNS eines Anbieters (z.B. afraid.org) ansprechbar oder über eine eigene Domain mit Namecheap, welche DDNS Updates der eigenen Domains zulassen.
-
Omnibus ist fürchterlich und die Codebase von GitLab bestenfalls mittelmäßig.
Omnibus ist Lippenstift für das Schwein, aber was soll man bei den Dependencies auch anderes erwarten?
https://github.com/gitlabhq/gitlabhq/blob/master/Gemfile.lockKlar, GitLab einmal zu deployen tut mit Omnibus nicht mehr weh, aber sowas längerfristig am laufen zu halten ist einfach mühsam.
So nett GitLab als User ist: Die Entwickler dahinter haben nicht übermäßig viel Ahnung davon was sie so tun. Siehe zB. tonnenweise Dependencies auf Gems, die sie selbst geforked haben, weil ihre mittelmäßigen Hacks upstream nicht angenommen wurden oder sie sonst einen Monat warten hätten müssen. Natürlich werden Upstream-Änderungen nie wieder eingepflegt und auch Sicherheitslücken dort kaum behoben. Aber wer weiß, vielleicht können sie ja einige ihrer Probleme mit dem Geld, mit dem sie gerade von Investoren beworfen werden, erschlagen.
edit: Hoppla, den letzten Absatz muss ich abschwächen; davon haben sie wohl einige Dependencies wieder rausgenommen, deren Upstream Bugs selbst behoben hat. Gibt ein paar Debian-Developer, die ordentliche Debian-Pakete für GitLab bauen und damit schon seit Monaten beschäftigt sind. Die dürften stark dazu beigetragen haben, den Ad-Hoc-Fork-Dependency-Irrsinn ein bisschen einzudämmen.
-
repository schrieb:
Wie macht ihr das eigentlich hardwaretechnisch. Habt ihr da zuhause im privaten Bereich eigene Hardware
Ja. Bevorzugt stromsparende kleine Maschinen; aktuell immer noch einen alten Sheevaplug, wobei es aktuell auch bessere Alternativen gibt.
Für alles, worauf man auch von extern zuverlässig Zugriff haben soll, verwende ich virtuelle Maschinen bei verschiedenen Anbietern (aktuell Linode und vultr).
-
nman schrieb:
Klar, GitLab einmal zu deployen tut mit Omnibus nicht mehr weh, aber sowas längerfristig am laufen zu halten ist einfach mühsam.
Also wir haben nun seit einem Jahr GitLab im Einsatz und keinerlei Probleme. Gerade die Updates laufen unglaublich flüssig. Ich habe noch selten so problemlose Updates erlebt. Gut, ich muss zugeben, dass Sicherheitslücken bei uns so gut wie keine Rolle spielen, da der GitLab Server nur im Intranet läuft und sich dort eine überschaubare Menge an Personen aufhält. Allerdings hatte ich bisher nicht das Gefühl, dass GitLab die Sicherheitsfragen nicht ernst nehmen würde. Und das von fertigen Lösungen die Codebasis nicht schön aussieht, dass ist leider auch nichts neues. Wenn eine Codebasis mittelmässig ist, dann ist das leider fast schon ein Grund zum feiern.
-
Vermutlich war ich bei GitLab auch einfach noch zu früh dran. Die ersten zwei Jahre waren wirklich die reinste Katastrophe. Sie haben sich um ihre Early Adopters überhaupt nicht bemüht und dauernd Sachen zerschossen und verschlimmbessert. Wäre ja fein, wenn das jetzt besser wäre und sie alles auch gut stabilisieren könnten.
