Hi,
ich möchte demnächst ein Projekt als Open Source veröffentlichen und
auch offen weiter entwickeln.
Ich benötige:
* Webauftritt (Hallo, worum geht es, News, etc.)
* Versionsverwaltung (muss SVN sein)
* Issue-Tracking (ich würde gerne Redmine benutzen)
* Wiki (für Tutorials, Hilfe, etc.)
* Forum (für Support)
Leider finde ich nichts, was meine Anforderungen so erfüllt.
Könnt ihr mir einen Tip geben?
Evtl. lohnt es sich einen eigenen Redmine Server aufzusetzen?
Das ganze sollte möglichst simpel und einfach zu pflegen sein.
Grüße,
Phil
Lukas S. schrieb:> SourceForge?
SourceForge war mal gut, aber ungefragt und wiederholt dort gehostete
Projekte mit Malware zu verseuchen geht gar nicht!
Philipp schrieb:> SourceForge war mal gut, aber ungefragt und wiederholt dort gehostete> Projekte mit Malware zu verseuchen geht gar nicht!
es gibt einen neue Besitzer, er will wieder alle ordentlich machen.
Auch wenn es deine Anforderungen nicht alle erfüllt, github ist echt
nicht schlecht. Wenn dir der Bugtracker nicht genügt, dann kannst Du ja
immer noch im Wiki einen Link zu einem extra Forum-Thread angeben.
Würde mich wundern, wenn Du auf das 'svn locking' nicht verzichten
könntest.
Zu Sourceforge:
Das fiel mir eher negativ in letzter Zeit auf. Vor allem dadurch, dass
gehostete Projekte nicht mehr erreichbar waren.
Philipp schrieb:> Evtl. lohnt es sich einen eigenen Redmine Server aufzusetzen?
Bisschen Aufwand ist es, SVN-Server musst du natürlich separat
aufsetzen.
Ich habe einen OpenProject-Server selbst laufen, habe ihn aber lieber
in einen Jail gesteckt (FreeBSD), um die Versionsabhängigkeiten vom
Host fernzuhalten.
Forum habe ich allerdings noch nicht getestet (bisher kein Bedarf).
Ansonsten läuft das brauchbar, und wird für ein paar Dinge bei uns
semi-produktiv genutzt, allerdings wenige Nutzer jeweils, nicht viel
Traffic.
savannah(.nongnu.org) fiele mir noch ein, da werden zwei der von mir
betreuten Projekte gehostet. Ist nicht so groß aufgezogen wie
SourceForge, die Admins scheinen das eher in der Freizeit zu machen,
aber ansonsten bin ich damit zufrieden. Ein richtiges Forum haben sie
jedoch nicht, sondern das, was sie "News" nennen, was aber so eine Art
Forum sein sollte.
Bei denen musst du aber auf jeden Fall unter eins der von ihnen
akzeptierten Lizenzmodelle passen. Für .nongnu.org kann das aber
beispielsweise auch BSD oder Apache license sein.
mar IO schrieb:> Würde mich wundern, wenn Du auf das 'svn locking' nicht verzichten> könntest.
Ich habe fast ausschließlich Code in Binärdateien.
Es handelt sich um Office VBA.
Wir nutzen z.Zt. ein privates SVN Repo, in dem diese Dateien beim Commit
automatisch auf "needs-lock" gesetzt werden.
Ist nicht so schön, weil immer nur einer daran arbeiten kann, vor allem
aber weil sich Versionen nicht vergleichen lassen.
Trotz dieser Nachteile funktioniert diese Methode für uns bisher recht
gut.
Wenn es dafür eine bessere Lösung gibt wäre ich dennoch sehr
interessiert.
Rene H. schrieb:> Selber hosten geht nicht?
Käme schon in Frage, allerdings scheue ich den Wartungsaufwand.
@Jörg:
Danke für deine Ausführungen!
OpenProject habe ich bei meinen Recherchen auch entdeckt.
Dort kann man auch gegen Geld hosten lassen.
Für Open Source Projekte wahrscheinlich weniger geeignet.
Planio wäre ein anderer kommerzieller Redmine Hoster.
Im Gegensatz zu Planio scheint OpenProject ein inkompatibler
Redmine-Fork zu sein, mit dem Anspruch eine bessere Usability zu bieten.
Kann man das so sagen?
Generell wäre ich auch bereit einen überschaubaren Betrag zu zahlen,
wenn denn das Paket stimmt.
Philipp schrieb:> Im Gegensatz zu Planio scheint OpenProject ein inkompatibler> Redmine-Fork zu sein, mit dem Anspruch eine bessere Usability zu bieten.> Kann man das so sagen?
Vermutlich, wobei ich Redmine nie ernsthaft im Einsatz hatte. Hatte
das mal als Prototypen, aber irgendwas war bei OpenProject wohl dabei,
was meine Frau für ihre Arbeit unbedingt haben wollte, deshalb haben
wir das dann damit aufgezogen.
Wenn du einen Testaccount haben willst, meld' dich (privat) bei mir.
Dann kannst du dir ein Spielprojekt aufsetzen.
TestX schrieb:> Schau dir doch mal den git workflow an...der ist ein wenig anderst als> bei svn...die builds werden über CI automatisch erzeugt etc...
CI Klingt interessant:
https://de.wikipedia.org/wiki/Kontinuierliche_Integration
Allerdings verstehe ich nicht, wie mir das bei meinem oben geschilderten
Problem (Ich habe fast ausschließlich Code in Binärdateien.) helfen
kann.
Philipp schrieb:> Ich habe fast ausschließlich Code in Binärdateien.> Es handelt sich um Office VBA.
das macht es für jede Art von Versionskontrollsystem ziemlich schwer zu
handhaben. Vor allem wirst Du nirgends vernünftige Diffs bekommen und
gerade das ist ja bei der Übernahme der Arbeit anderer in einem
Opensource-Projekt entscheidend.
Kann man den Code aus dem Office VBA nicht auch in normalen Textdateien
pflegen und dann irgendwie automatisiert ins binäre Officeformat
übernehmen? Z.B. per Makefile oder ähnlichem.
Das wäre das erste was ich bei sowas machen würde, denn rein mit
Binärformaten kannst Du meiner Meinung nach nicht vernünftig entwickeln.
Philipp schrieb:> mar IO schrieb:>> Würde mich wundern, wenn Du auf das 'svn locking' nicht verzichten>> könntest.>> Ich habe fast ausschließlich Code in Binärdateien.> Es handelt sich um Office VBA.> ...> Wenn es dafür eine bessere Lösung gibt wäre ich dennoch sehr> interessiert.
Ich könnte nur weitere Fragen stellen, da ich mich mit VBA nicht
auskenne. Lustigerweise habe ich das in der Berufsschule als Alternative
zur Programmiersprache gelernt (IT-SE).
Das mit 'ausschließlich Binärdateien' klingt für mich nicht unbedingt
auch svn geeignet, aber egal... Ich bin auch mal auf Binär Repository
gestoßen, ob das geeignet ist, k.A..
Jedenfalls würde ich mich nicht gleich zu anfangs übernehmen und mal
gucken, wie das andere Leute mit VBA Skripte (z.B. auf Github) machen.
Timmo H. schrieb:> Hätte jetzt auch erstmal github gesagt...Klar kein SVN, aber SVN wird> doch langsam eh obsolet. SVN kann man wunderbar zu git portieren.Gerd E. schrieb:> das macht es für jede Art von Versionskontrollsystem ziemlich schwer zu> handhaben. Vor allem wirst Du nirgends vernünftige Diffs bekommen und> gerade das ist ja bei der Übernahme der Arbeit anderer in einem> Opensource-Projekt entscheidend.
Es gibt einige Programme mit integrierter Unterstützung für
Versionskontrollsysteme. Das kann sehr praktisch sein, z.B. bei Altium
Designer; dort funktioniert die Erzeugung von Diffs mit Hilfe des
Storage Managers nur bei CVS, SVN und natürlich Altium Vault, jedoch
nicht mit Git o.ä.. Es gibt wohl schon mehrere Leute, die bei Altium
wegen der Implementierung einer Git-Unterstützung nachgefragt haben;
dies wurde jedoch abgelehnt. Der einzige Grund, warum SVN in diesem
Zusammenhang obsolet werden könnte, wäre die Entfernung des SVN-Moduls,
um die Kunden zum Kauf des ziemlich überteuerten Altiums Vaults zu
zwingen. Das würde aber sicherlich gewaltig nach hinten losgehen. Altium
Vault basiert intern übrigens wohl auch auf SVN.
Gerd E. schrieb:> Das wäre das erste was ich bei sowas machen würde, denn rein mit> Binärformaten kannst Du meiner Meinung nach nicht vernünftig entwickeln.
Selbst wenn sich einige Programme von Binär- und Textformate umstellen
lassen, bedeutet das noch lange nicht, dass man die Resultate problemlos
mergen kann. Ich kenne ein Projekt, in dem das Mergen von
Enterprise-Architect-Projektdateien im Textformat immer wieder gewaltig
nach hinten losgegangen ist. Das, was einem außerhalb des jeweiligen
Programms durchgeführten Merge-Vorgang nämlich fehlt, sind die
Konsistenzprüfung der Projektdateien sowie ggf. die Korrektur interner
Verweise.
So sehr ich die Verwendung von Locks bei Versionskontrollsystemen hasse,
so sehr muss ich leider deren Notwendigkeit beim Einsatz einiger
Entwicklungsumgebungen anerkennen.
Philipp schrieb:> Ich habe fast ausschließlich Code in Binärdateien.> Es handelt sich um Office VBA.
Oh Gott, Erinnerungen aus der Zeit der Jahrtausendwende kommen hoch
(MS-Access, replizierte Datenbank, offline, Synchronisieren übers Modem,
Unlösbare Konflikte). Ich sehe VBA, tonnenweise VBA, kreuz und quer über
das ganze Ding verteilt, an jedem Formular hängt VBA mit dran, Ich fühle
Schmerzen, Verzweiflung. Ahhhrg. Aufhören!
Gerd E. schrieb:> Vor allem wirst Du nirgends vernünftige Diffs bekommen und> gerade das ist ja bei der Übernahme der Arbeit anderer in einem> Opensource-Projekt entscheidend.
Das stimmt.
Im Moment arbeiten wir zu zweit und sprechen uns ab, bzw. arbeiten eh an
verschiedenen Bereichen.
Sollten Beiträge von außen kommen wäre das aber ein erstes Problem.
Gerd E. schrieb:> Kann man den Code aus dem Office VBA nicht auch in normalen Textdateien> pflegen und dann irgendwie automatisiert ins binäre Officeformat> übernehmen?
Es gibt Möglichkeiten.
Ich habe bereits Code, der den gesamten Code aus allen Modulen in
einzelne Dateien exportiert. Import ginge auch. Allerdings muss man das
in den Sicherheitseinstellungen vorher explizit erlauben (Trust access
to the VBA project object model).
Es ist halt ein Arbeitsschritt mehr, daher nutzt das keiner...
Ich muss mal schauen, ob man Tortoise beibringen kann vor dem Commit
noch ein Script auszuführen. Das besten wäre sogar, wenn es gleich
Serverseitig erledigt würde.
Philipp schrieb:> Im Moment arbeiten wir zu zweit und sprechen uns ab, bzw. arbeiten eh an> verschiedenen Bereichen.
Arbeitet Ihr im Trunk oder in verschiedenen Branches?
Andreas S. schrieb:> Selbst wenn sich einige Programme von Binär- und Textformate umstellen> lassen, bedeutet das noch lange nicht, dass man die Resultate problemlos> mergen kann.
klar.
Aber bei einem sinnvoll (und evtl. sogar dokumentiert) strukturierten
Textformat kannst Du meist mit überschaubarem Aufwand ein Skript
schreiben, welches die Konsistenz prüft oder gar wiederherstellt.
Auch bedeutet ein Textformat nicht automatisch daß Du die Diffs sofort
"lesen" kannst. Aber oft gibt es schon was fertiges für das Format (z.B.
für Diffs über XML) oder Du kannst auch hier kurz selbst Hand anlegen.
Bei sehr schlecht dokumentierten und komplexen Binärformaten (wie z.B.
MS Office Makros) ist das dagegen um Längen komplexer.
Nur im Trunk.
Dort hat auch jeder seine Spielwiese wo er neue Sachen ausprobieren
kann.
Dann ist es zumindest versioniert und für alle verfügbar.
Branchen / mergen passt leider nicht zu unserem Entwicklungsmodel mit
Binärdateien.
Philipp schrieb:> Ich habe bereits Code, der den gesamten Code aus allen Modulen in> einzelne Dateien exportiert. Import ginge auch. Allerdings muss man das> in den Sicherheitseinstellungen vorher explizit erlauben (Trust access> to the VBA project object model).
Vielleicht kann man das mit den Trust-Einstellungen auf bestimmte
Verzeichnisse oder Projekte beschränken. Dann sähe ich da kein Problem
drin.
> Es ist halt ein Arbeitsschritt mehr, daher nutzt das keiner...> Ich muss mal schauen, ob man Tortoise beibringen kann vor dem Commit> noch ein Script auszuführen.
Automatisieren ist klar das beste.
> Das besten wäre sogar, wenn es gleich> Serverseitig erledigt würde.
Dann musst Du aber doch Office auf dem Server laufen haben? Das macht
die Sache wesentlich komplexer.
Ansonsten würde Dir der Umstieg auf Textformate den ganzen Ärger mit den
Locks ersparen. Und Du könntest auch gleich git nehmen und müsstest
nicht auf das meiner Meinung nach vor allem für ein OpenSourc-Projekt
nicht mehr zeitgemäße svn setzen.
Gerd E. schrieb:> das macht es für jede Art von Versionskontrollsystem ziemlich schwer zu> handhaben.
Konkurrierender Zugriff ist ja nun nicht der einzige sinnvolle Grund,
warum man insgesamt eine Versionierung möchte.
Gerd E. schrieb:> Ansonsten würde Dir der Umstieg auf Textformate den ganzen Ärger mit den> Locks ersparen.
Auch nur, wenn sie sich sinnvoll mergen lassen. Gerade bei XML kommt
da oft genug Humbug raus, weil die paar Zeilen Kontext, die ein Diff
mit sich bringt, dort eben keine sichere Basis mehr für die genaue
Erkennung der zu mergenden Stelle sind.
Es ist ja auch nicht nur der Code in den Binärdateien, sondern auch
andere Dinge die sich eben nicht in Textdateien exportieren lassen.
Oft ist es sogar so, dass eine Codeänderung mit einer Änderung in den
Binärdaten einher geht.
D.h. selbst wenn ich den Code nebenher in Textdateien tracke kann ich
nie sicher sein, dass sich nur der Code geändert hat.
Ich kann also den Code nicht einfach importieren, sondern muss eh die
neue Binärdatei komplett übernehmen.
Die Textdateien würden nur beim Review helfen.
Beim Mergen nur so lange, wie alle noch ganz sicher wissen was genau
gemacht wurde.
Code der unseren Code exportiert habe ich ja selbst schon geschrieben.
Aber ich denke noch mal darüber nach.
Gerd E. schrieb:> Dann musst Du aber doch Office auf dem Server laufen haben?
Vermutlich ja, und Windows...
Gerd E. schrieb:> Ansonsten würde Dir der Umstieg auf Textformate den ganzen Ärger mit den> Locks ersparen. Und Du könntest auch gleich git nehmen und müsstest> nicht auf das meiner Meinung nach vor allem für ein OpenSourc-Projekt> nicht mehr zeitgemäße svn setzen.
Hätte was, aber dazu siehe meinen Post oben.
Für den Moment sind wir ja auch zufrieden mit unserem Entwicklungsmodel.
Wie das wird, wenn andere Entwickler hinzukommen muss man dann sehen.
Ich glaube auch nicht, dass es viele externe Beiträge geben wird.
In erster Linie geht es uns darum den Anwenderkreis zu vergrößern,
Erfahrungen zu sammeln und evtl. künftige Chancen aufzutun.
Gerd E. schrieb:> Vielleicht kann man das mit den Trust-Einstellungen auf bestimmte> Verzeichnisse oder Projekte beschränken. Dann sähe ich da kein Problem> drin.
Nein, lässt sich nicht einschränken, schau einfach mal bei dir z.B. in
Excel nach.
Mein Problem ist auch weniger die Sicherheit.
Die Leute sind es bei GitHub gewohnt einfach zu forken und dann einen
Pullrequest zu senden.
Bei uns wären dazu aber noch viel mehr Schritte und solche Einstellungen
nötig. Das ist einfach zu kompliziert, das macht keiner.
Dem Kernteam kann man das ja noch zumuten, nicht aber dem User der auch
mal was beitragen möchte.
Philipp schrieb:> Die Leute sind es bei GitHub gewohnt einfach zu forken und dann einen> Pullrequest zu senden.
genau. Dann siehst Du auch gleich im Diff ob das sinnvoll ist oder ob
noch Ergänzungen nötig sind.
> Bei uns wären dazu aber noch viel mehr Schritte und solche Einstellungen> nötig. Das ist einfach zu kompliziert, das macht keiner.> Dem Kernteam kann man das ja noch zumuten, nicht aber dem User der auch> mal was beitragen möchte.
Was soll der User der was beitragen möchte denn sonst machen?
Bei Dir anfragen, seinen SSH-Key schicken, damit Du den auf dem Server
freischaltest, dann einen svn lock machen, seinen Kram einchecken und
dann wieder freigeben?
Das halte ich für noch viel unpraktikabler.
Da doch lieber ein kleines Readme was die Toolchain und das Setup
erklärt.
Vielleicht findest Du auch auf den oben geposteten Links noch eine
Variante wie Du das noch vereinfachen kannst.
Gerd E. schrieb:> Was soll der User der was beitragen möchte denn sonst machen?
Mir die Datei schicken.
Ich exportiere dann den Code und schau mir das an.
Nach x sinnvollen Beiträgen bekommt er SVN Schreibrechte.
Gerd E. schrieb:> Vielleicht findest Du auch auf den oben geposteten Links noch eine> Variante wie Du das noch vereinfachen kannst.
Die Links implementieren ja im wesentlichen auch nur Code Im- und
Export.
Export habe ich bereits, und Import hilft nicht, siehe meinen Beitrag
oben:
> Es ist ja auch nicht nur der Code in den Binärdateien, sondern ...
Irgendwann kann man das ganze ja mal mit .NET umsetzen, dann sind Code
und Binärdaten auch sauber getrennt.
Allerdings sind wir mit den Resultaten mit VBA bisher sehr zufrieden.
;)
nicht alles war schlecht damals, und nicht alles ist heute besser.
Ich finde GitHub wirklich toll und interessant (soweit ich es von außen
beurteilen kann), würde echt gerne damit arbeiten.
Allerdings sehe ich im Moment überhaupt nicht, wie das für uns sinnvoll
funktionieren soll.
Vor allem will ich es nicht mit Gewalt über unser Entwicklungsmodel
stülpen.
Im Moment läuft es gut genug.
Wenn es nicht mehr gut genug läuft, dann werden wir das lösen.
Zur eigentlichen Frage:
Im Moment schwanke ich zwischen SourceForge und Planio / OpenProject.
Mit letzteren Beiden scheine ich leider keinen vernünftigen Webauftritt
zu bekommen.
Außerdem ist die Zahl der Nutzer an Pakete (Geld) gebunden.
Entwickler müssen es ja nicht so viele sein, aber jeder Soll aufs Forum
zugreifen und Issues einstellen können.
Bei SourceForge würde ich Redmine vermissen, ansonsten ist alles da.
