[vz-dev] Fw: libsml unmaintained ? war: Re: libsml: do not printf errors on stdout, please use fprintf(stderr, ...) instead #9

[justin at justinotherguy.org]

Moin,

> Am 02.01.2015 um 12:21 schrieb devzero at web.de:
> 
> versteht mich hier nicht falsch - ich habe nichts gegen juri, ich habe nur ein problem damit, wenn gpl`de opensource software eine "one man show" ist und andere größere softwareprojekte von solch einer software abhängig sind. 
> 
> und  ich habe ein problem damit, wenn für eine gpl`ed software keine kontaktadressen existieren, um z.b. fragen zu stellen oder um sich zu dieser software gemeinschaftlich auszutauschen.
> 
> damit wird kommunikation und fortentwicklung unterbunden und letzten endes bedeutet das: "friss oder stirb".
> 
> das ist keine gesunde basis für eine opensource-software.
> 
> jemand der sich für sml interessiert findet womöglich libsml. und dannn kann er das runterladen und damit rumspielen. und weiter ?  wenn er sich über libsml mit anderen libsml nutzern austauschen will - was dann? dann kann er google nutzen und vielleicht findet er raus, daß er eventuell in der volkszähler mailingliste gut aufgehoben wäre. und jetzt betrachte man das mal noch aus sicht einer person die der deutschen sprache nicht mächtig ist…

ich glaube, die Frage ist eine andere.

Die Frage „to fork or not to fork?“ stellt sich m.E. nicht; bei git (im Ggs. zu beispielsweise CVS) ist ein Fork der erste Schritt; schon für die kleinste Änderung kannst Du einen Fork erstellen, Deine Änderungen vornehmen und dann einen PR stellen.
Wird dieser vom DAI-Labor eingearbeitet, ist alles gut (und Du kannst den Fork wieder auflösen). Wird dieser nicht eingearbeitet, ist der neue Fork eben der neuste.

Nur in dem Fall stellt sich die Frage, ob wir libsml unter den Projekt-Account bei github nehmen oder nicht. Das ergibt m.E. aber nur Sinn, wenn wir davon ausgehen, dass wir das auch dauerhaft (TM) pflegen können. libsml hat ja immerhin in der Vergangenheit nur sehr wenig Korrekturen erfordert - unschön wäre m.E., wenn wir das „zu uns nehmen“ und dann aber in 6 oder 12 Monaten selbst auch nicht in der Lage sind, fremde PRs zu bewerten.

Drum mein Vorschlag:
- derjenige, der sich das zutraut, sollte libsml forken, die Änderungen vornehmen und einen PR an dailab stellen
- falls dieser nicht eingearbeitet wird, können wir libsml bei uns aufnehmen


>> Gesendet: Freitag, 02. Januar 2015 um 12:06 Uhr
>> Von: devzero at web.de
>> An: volkszaehler-dev at demo.volkszaehler.org
>> Cc: "volkszaehler.org" <volkszaehler-dev at demo.volkszaehler.org>
>> Betreff: libsml  unmaintained ?  war: Re: [vz-dev] libsml: do not printf errors on stdout, please use fprintf(stderr, ...) instead #9
>> 
>>> ansonsten wird es aber vermutlich langfristig am sinnvollsten sein,
>>> einen eigenen fork im volkszaehler projekt zu haben.
>> 
>> was sagt denn das vz-projekt dazu? 

was „das Projekt(TM)“ dazu sagt, kann ich nicht sagen - meine 2 ct stehen oben. Mich interessieren weitere Meinungen dazu.


>> ps:
>> Das Dai-Lab hat in Sachen Smart-Home auf Basis SolidRun/CuBox ja scheinbar "Großes" vor:
>> 
>> http://www.dai-labor.de/ueber_uns/pressemitteilungen/single_view/article/dai-labor-der-technischen-universitaet-berlin-praesentiert-erstmals-die-interoperable-smart-home-pla/
>> http://www.io-lite.de

aha, interessant.


Gruß, J.