D

DonAlfonso

Sorry, das war schlecht ausgedrückt. Nen ITler bekommt man natürlich nicht für 29€ (zumindest keinen, den man haben will). Aber ein gutes Mailhosting schon. Auch aus DE und mit gutem Track-Record.

Ich glaube, du bist getriggert, nicht ich. Ich sage doch nicht, dass sowas wie der “stupid mistake” nicht passieren darf. Darf und tut es selbstverständlich! Ich möchte nur nicht selbst entscheiden müssen, ob jeder Commit für mich relevant ist und ob ich updaten muss oder nicht. Also warum dann nicht einfach Releases machen, wenn es für den normalen Mailcow-User was zu tun gibt? Ist doch nicht so schwer, oder?

Aber du bist hier der Boss, es ist dein Produkt. Das respektiere ich, aber mitarbeiten möchte ich da bitte nicht (bist du vielleicht auch ganz froh drum, oder?). Für nen simplen Mailserver wäre mir das zu stressig. Dann mal noch viel Erfolg und viel Spaß damit

Keine Ahnung ob @tkorves jetzt mich angesprochen hat, ich vermute es aber mal. Also: Ich habe weder von Boeing, Microsoft o.ä. geredet. Ich habe auch nicht gesagt, dass ich kostenlose Wartung oder Support haben möchte. Von Geiz ist geil kannst du also nicht reden.

Alles, was ich mir wünschen würde, ist ein etwas strukturierteres Release-System. Schau doch mal ins Github rein, z.B. den Commit mailcow/mailcow-dockerized20e289c. Wenn ich jetzt als Admin die Commits verfolge, wüsste ich nur, dass jemand nen “stupid mistake” gefixt hat. Ich weiß weder, was der Fehler ist, noch ob er mich betrifft. Muss ich jetzt also updaten? Ist der Fehler am Ende kritisch? Ich glaube nicht, dass ich damit “Ansprüche stelle”, die soo ungewöhnlich sind - selbst im Open-Source-Bereich.

Und an @diekuh: Ich habe nicht gesagt, dass du nicht genau hinschaust. Ich glaube dir sogar, dass du das gut machst. Genau deshalb habe ich für meine private Mailcow auch mehrere stay-awesome-Lizenzen erworben. Für einen seriöseren Einsatz ist mir das aber ehrlich gesagt zu frickelig. Ich möchte bei einem Mailserver nicht Commits lesen und verstehen müssen. Und wenn ich ein Support-Paket kaufen muss, um das nicht zu müssen, dann kann ich auch gleich zu einem Profi gehen, der mir dann gleich alles abnimmt. Teurer wäre das definitiv nicht.

Und falls das Argument gegen einen strukturierteren Release die fehlende Manpower ist, dann unterstützt das leider nur mein mulmiges Gefühl bei der Sache. Ich kenne zu viele One-Man-Shows im Open-Source-Bereich, die genau wegen sowas von heute auf morgen untergegangen sind.

Hmm aber du schreibst doch selbst, dass man „garantiert stabile Updates“ nur über ein Support-Paket bekommt. Oder darunter:

diekuh Der “master” Branch ist zwar in der Regel stabil. Es gibt jedoch Zeiten, in denen wir größere Änderungen pushen und dann dazu raten zu abzuwarten. Wir freuen uns trotzdem sehr, wenn der Code von vielen frühst-möglich gegengeprüft wird.

„In der Regel“ klingt für mich schon irgendwie ein bisschen nach „auf gut Glück“. Ich verstehe das ja, natürlich möchtet ihr Support-Pakete verkaufen ;-) Und kostenlose Tester sind auch immer nice.
Es hat schon aber auch seinen Grund, dass die meisten quelloffenen, kostenfreien Server-Distros in den Stable-Branches eben nicht auf ein reines Rolling Release setzen. Und ich hätte schon gerne, dass eine kritische Anwendung wie ein Mailserver rund läuft. Features brauche ich da nicht alle paar Wochen, sondern Stabilität. Kostenlos und quelloffen hin oder her.

Das Thema interessiert mich auch. Das heißt also, wenn ich nicht ständig nachschauen möchte, muss ich das Repo watchen. Dann bekomme ich doch aber jeden Commit mit und muss selbst entscheiden, wann ich update. Das kann doch nicht so gemeint sein, oder?! Ich weiß doch gar nicht, an was ihr da gerade arbeitet, ob das schon fertig implementiert ist usw.

Warum denn nicht einfach in Github Releases machen? Dann könnt ihr der Community signalisieren, dass ihr “fertig” seid, und man muss nicht auf gut Glück updaten und jeden einzelnen Commit mitverfolgen.