Ideen/Mitstreiter gesucht: "snom-patches" statt Bristuff

[pwalker]

Da mir Bristuff irgendwie nicht mehr so recht "am Leben" zu sein scheint (siehe auch hier und hier), ich aber gerne die darin vorhandenen Erweiterungen/Anpassungen (= Patches an Asterisk) speziell/v.a. für snom-Telefone verwende, kam ich (wieder mal...) auf die Idee, etwas eigenes ins Leben zu rufen, also eine Patch-Sammlung für Asterisk und snom.
Jemand interessiert? Ideen wie (Form; svn, git, ...) und was (Inhalt; welche Patches, siehe auch Patches hier im IPPF) machn machen könnte? Oder gibt es so was bereits?

Gruss,
Philipp

P.S.: Ich weiss, der "saubere" Weg, das zu "handlen" wäre über Asterisk, doch das scheint mir auch nicht ganz unproblematisch (Patches werden meist nur in den Trunk reingenommen, und nicht immer akzeptiert, u.a. wenn sie nur "speziell" für einen Telefon-Hersteller sind, je nach dem von wem die Patches kommen, ...)

 

[anhalter42]

Ich trage mich auch schon mit so einer Idee, da wir ja eine ähnliche Konfiguration und Probleme haben. EazyAdm machte hier und hier schon zwei Angebote für ein Wiki und ich denke "Asterisk + Snom" sollte da der "Zweig von Interesse" sein. Mir wäre es allerdings deutlich lieber, bristuff würde diese Funktion wahrnehmen: so etwas wie das "europäische Flair" von Asterisk - hier gibt es vielleicht doch größere Unterschiede in der Wahrnehmung zwischen den US-Amerikanern und den Europäern, was eine Telefonanlage (in einer Firma?) können sollte.

 

[EazyAdm]

Jou, wäre auch dabei. Zum einen Doku, zum anderen auch Umsetzung. Da ich mich gerade verstärkt in die 1.6 Fresse, denke ich das ich doch ganz gut mitwirken kann.

Generell finde ich es eine super Idee von den Hersteller Patches weg zu gehen und eine eigene Patchsammlung zu machen die dann eben auch entsprechend (achtung tolles Wort) gemaintained wird.

Denn aktuell gibt es 1000 Patches ohne Doku und ohne Info von was Sie abhängen und zu welcher Version Sie passen geschweigeden was Sie tatsächlich tun.

Bye
eazy

 

[pwalker]

Stimmt, neben Form und Inhalt wäre Doku auch noch ein Thema. Ich denke, ein Wiki wäre da ein guter Ansatz.
Aber zum "Verwalten" des Codes und die Info welcher Patch für welche Version ist, bräuchte man m.E. wohl git oder so was, wo man den Code schlau verwalten und taggen kann. Die Copy&Paste-Technik aus einem Wiki (oder Wiki-Up- und Downloads) finde ich da nicht so prickelnd.

 

[pwalker]

Mir wäre es allerdings deutlich lieber, bristuff würde diese Funktion wahrnehmen:

Aufgrund u.a. meines Mail-Verkehrs mit dem Maintainer der Xorcom-Bristuff-Version sieht das da eher schlecht aus...
Und andererseits macht auch die Trennung von der "BRI-Funktionalität" von Bristuff und den Patches, z.B. für SIP durchaus Sinn.

so etwas wie das "europäische Flair" von Asterisk

"Euro-Asterisk" - tönt sogar für mich als Schweizer gut. Erhebst Du Copyright-Ansprüche auf das "europäische Flair von Asterisk"?

hier gibt es vielleicht doch größere Unterschiede in der Wahrnehmung zwischen den US-Amerikanern und den Europäern, was eine Telefonanlage (in einer Firma?) können sollte.

Full ACK!

 

[EazyAdm]

Stimmt, neben Form und Inhalt wäre Doku auch noch ein Thema. Ich denke, ein Wiki wäre da ein guter Ansatz.
Aber zum "Verwalten" des Codes und die Info welcher Patch für welche Version ist, bräuchte man m.E. wohl git oder so was, wo man den Code schlau verwalten und taggen kann. Die Copy&Paste-Technik aus einem Wiki (oder Wiki-Up- und Downloads) finde ich da nicht so prickelnd.

Wenn man das Thema ne angeht sollte man direkt eine ordentliche Versionierung, Bugtracking und Roadmap verwaltung haben. Ich denke Trac würde ich da anbieten. Haben wir bei vielen anderen Projekten auch im Einsatz.

Wenn der Thread hier tatsächlich fruchtet und sich 4-5 Freiwillige finden die das ganze mit anstossen, stelle ich gerne einen SVN Server mit Trac zur Verfügung. Somit haetten wir alles unter einem Hut.

Bye
eazy

 

[pwalker]

Wenn man das Thema ne angeht sollte man direkt eine ordentliche Versionierung, Bugtracking und Roadmap verwaltung haben. Ich denke Trac würde ich da anbieten. Haben wir bei vielen anderen Projekten auch im Einsatz.

Den "alles unter einem Hut"-Ansatz finde ich gut, bin aber persönlich nicht so ein riesiger Fan von Trac (u.a. wegen dessen Wiki).

 

[EazyAdm]

Hmm OK, das höre ich zum ersten mal. Aber ich bin offen für Neues. Was gibt es als alternative? Mir wäre nämlich keine bekannt.

bye
eazy

 

[pwalker]

Hmm OK, das höre ich zum ersten mal. Aber ich bin offen für Neues. Was gibt es als alternative? Mir wäre nämlich keine bekannt.

Ist auch nur meine persönliche Meinung, aber ich ich könnte sicher auch mit Trac leben, daran sollte es nicht scheitern - bin da auch etwas anpassungsfähig/kompromissbereit.
Alternative gibt's ein paar, aber die kommen glaubs nicht so recht an Trac ran. Tante Google liefert bei der Suche nach "alternative trac" einige Resultate.

 

[anhalter42]

Mir ist es ehrlich gesagt egal, ob da Tic, Tric oder Trac dahinter stecken ;-) Ich gehe davon aus, dass das Ding leben wird, wenn es gut benutzbar ist und bleibt und da muss m.E. der Ansatz sein:

- die Funktionalität(en) mal in einfachem Deutsch beschreiben (ohne Jargon à la BLF), wirklich so: A ruft B an, C sieht das im Display in der Form A>B, drückt das Knöpfchen x und sieht dann in seinem Display A (und nicht etwa B oder *8B o.ä.). Vielleicht dann die ganze Beschreibung nochmal in Jargon, damit die How-Tos kürzer werden. Dort suche ich mir etwas raus.

- von dort müssen die Asterisk-Versionen auswählbar sein - einmal mit, einmal ohne Bristuff-Patch,

- dann wiederum eine Liste der Snom-Telefone und die der Firmwares. Ihr wisst sicher selber, dass dieselbe Funktionalität manchmal von Telefontyp zu Telefontyp auf derselben Firmware ruckelt.

Erst dann kann es verschiedene Möglichkeiten der Umsetzung dieser Funktionalität geben (=Wiki). Wichtig sind dann auch Hinweise, ob die gerade diskutierte Möglichkeit mit anderen Funktionalitäten etwas zu tun hat: sie (im besten Falle) auch mit umsetzt, sie evtl. stört oder was weiß ich.

Die How-Tos der Möglichkeiten, die dann natürlich sehr speziell sind, an denen ich nach bestem Wissen und Gewissen auch mitschriebe, sollten dann erst Links zu den Patches haben.

Eine allgemeine Anleitung zum Patchen von Asterisk (die gibt es ja) sollte auch nicht fehlen.

Offen ist für mich
- wie mit Trixbox und Co. umgegangen werden soll
- inwieweit Hardware eine Rolle spielt (HFC-Karte oder octoBRI oder Pattons). Das weiß ich mangels Hardwarezoo nicht.

 

[EazyAdm]

OK, ich denke die Resonanz ist ausreichend es werden mit Sicherheit noch einige dazu kommen sobald die Plattform steht. Ich werde einen Trac aufsetzten. Sobald das System rennt werde ich den Link hier Posten und dann kann es los gehen.

Bye
eazy

 

[foschi]

Als Plattform würde sich doch auch sourceforge.net anbieten, da sollte alles vorhanden sein (repository, bugtracker etc).

Bei entsprechender Resonanz richten wir dann ein eigenes Subforum ein, in dem die Kommunikation laufen kann.

 

[EazyAdm]

auch gut, allerdings keine erfahrung ... aber ich les mich da gleich mal ein.

danke

 

[pwalker]

Als Plattform würde sich doch auch sourceforge.net anbieten, da sollte alles vorhanden sein (repository, bugtracker etc).

Taugt SF dafür?
Als Alternativen währen noch mindestens Launchpad, evtl. GitHub und evtl. weitere zu erwähnen. Jemand Erfahrung mit dem einen oder anderen davon?

 

[anhalter42]

Und andererseits macht auch die Trennung von der "BRI-Funktionalität" von Bristuff und den Patches, z.B. für SIP durchaus Sinn.

Da musste ich erst drüber nachdenken. Du meinst also, dass man das in einen BRI-Teil und einen Snom(=SIP)-Teil trennt? Das scheint mir sogar logisch. Dann wäre der Snom-Stuff herausgelöst (aus dem BRI-Stuff und weiterentwickelt) dann immer abhängig von Asterisk-Version und Snom-Firmware-Version... also sowas wie Middleware... Da tun sich Abgründe auf...

Jetzt wird's etwas Off Topic:
Warum ich an Middleware denke: nicht für jeden ist es so leicht, den Asterisk zu patchen. Ich z.B. habe eine Produktivanlage, an der ich tunlichst wenig verändere. Andererseits habe ich wenig Hardware (wir haben keine zweie octoBRI auf Halde) und Zeit, das alles parallel zu testen. Eine Middleware wäre dann ein Konstrukt, dass ich dazwischenschalten *könnte* und im schlimmsten Fall einfach wieder abschalte.

Falls ich jetzt den Begriff Middleware falsch verwendet habe, bitte ich um Entschuldigung, Ihr habt hoffentlich trotzdem verstanden was ich meinte.

"Euro-Asterisk" - tönt sogar für mich als Schweizer gut. Erhebst Du Copyright-Ansprüche auf das "europäische Flair von Asterisk"?

Das war schon etwas hochgegriffen, da ich ehrlich gesagt nicht genau weiß, was z.B. in Frankreich, Italien oder Griechenland so üblich ist, aber schön, wenn Ihr dabei seid.