Discussie over de toekomst van ZFSguru

[syl765]

Misschien heb je die gemist of heb je vanaf dat moment op een andere link geklikt.

Kijk, dat is dus waar het mis kan gaan. Hoe kan ik iets missen tijdens de install ??
Laat toch zien dat het een beetje vreemd door elkaar loopt. Misschien ben ik de enige die dit heeft, maar het voelt allerminst als soepel.
Misschien komt het door alle andere installers van andere unix varianten.
Persoonlijk denk ik dat welcome wizard en de installer toch beter gescheiden zouden moeten worden.

gr
johan

[ Voor 34% gewijzigd door syl765 op 14-01-2014 16:48 ]

[Verwijderd]

Maar geen Ubuntu installeren terwijl je Ubuntu draait, op dezelfde disk. Bij ZFSguru kan dit wel. Volgens mij het enige OS voor zover ik weet dat dit ondersteunt en zelfs de normale gang van installatie is.

[CurlyMo]

XBian kan het ook. Maar niet via de installer (beperking van de RPi). Als je update kan je achteraf ook een oudere snapshot booten.

[syl765]

Dat is expres op 28 gelaten. Als je LZ4 instelt, wordt de pool sowieso automatisch geupdate naar v5000. v28 is de beste en meest compatibele ZFS versie. Dat wordt als 'modern' gezien. v5000 als 'next gen' maar dus ook incompatible met Solaris ZFS.

Maak dan 4 opties.

Next gen (5000)
Modern (28)
Reduced ZFS version, compatible with older platforms ( ?? ) Welke versie pakt ZFSguru dan ?
Custum Version

[FireDrunk]

@CiPHER, ik vind versie 5000 helemaal niet 'next-gen'... Het is eerder de standaard... v28 is juist eerder backwards compatible... De default in de FreeBSD installer is origineel ook al v5000. Als ze er daar vertrouwen in hebben, waarom dan niet dat de default maken

[Verwijderd]

@syl765: die opties zijn er ook, je kunt zelf custom aangeven dat je v5000 wilt. Ook staat er een blauwe link naast met help choose version, in elk geval op de Pools->Create pagina.

En over het scheiden van Welcome Wizard en installatie: dat is juist al gescheiden. Als jou goed begrijp pleit je eerder voor het integreren van allebei ipv scheiden, want je zag de welcome wizard al aan voor de installatie en verwachtte dat je na de welcome wizard al geïnstalleerd had en moet rebooten. Dit terwijl de Welcome Wizard je enkel een link naar de installatie geeft; verder zijn de twee helemaal gescheiden.

@FireDrunk:
ZFSguru heeft de filosofie dat compatibiliteit heel belangrijk is. Met name wil ZFSguru het makkelijk maken te switchen tussen verschillende platforms. Vandaar dat ZFSguru ook GEOM-formatting heeft wat beter werkt voor Solaris OS, en nog meer van dat soort dingen.

Nu is er ook geen reden om standaard v5000 te hebben. Vroeger was v15 ook standaard. Wil je dedup gebruiken of andere features? Upgrade dan naar v28. Met v5000 is dit eigenlijk niet anders; v28 is tegenwoordig standaard en wordt overal gesupport (Solaris, IllumOS, BSD, Linux, Mac OSX) maar v5000 niet en zelfs voor ZFSguru is die support vrij nieuw.

En waarom zou je v5000 willen als je de features niet gebruikt? Enige 'feature' die je dan krijgt is incompatibiliteit. Wat veel beter is, is dat je standaard v28 gebruikt en pas zodra je LZ4 compressie activeert op de Files pagina voor een filesystem, dat je pool dan naar v5000 wordt upgrade. Dat is ook zo geimplementeerd, je krijgt ook een melding als je pool v28 is en geupgrade gaat worden naar v5000.

Kortom, ik sta juist achter v28 als default houden. Heeft eigenlijk alleen maar voordelen en eigenlijk geen nadelen.

[syl765]

Kortom, ik sta juist achter v28 als default houden. Heeft eigenlijk alleen maar voordelen en eigenlijk geen nadelen.

Maak dan duidelijk welke versie het is.
Voor mij is Modern 5000 en compatible 28 als er tussen () het versie nummer had gestaan, dan was het duidelijker.

Ik zal vanavond de installatie nog eens doen, ik ga dus uit van dat ik de CD download, deze start en een installatie wil doen.
Dat is toch wat de meeste zullen doen.
De FreeBSD CD is ook een installer, en een rescue CD, maar ik heb wel de keuze.

De meeste gebruikers zullen de CD toch als installer gebruiken of heb ik het mis!
Je begint met de welcome wizard, en die zou de keuze moeten geven.

[Verwijderd]

Staat er toch? Als je op reduced version klikt, dan springt de SPA naar 15, modern naar 28. De getallen die je ziet komen dus overeen met de optie die je hebt geselecteerd. Mogelijk wel dat deze functionaliteit afwijkt van de Welcome Wizard; misschien doel je daar op. Ik gebruik die wizard zelf niet.

De meeste gebruikers zullen de CD toch als installer gebruiken of heb ik het mis!

Klopt al kun je ook bij een Root-on-ZFS installatie doen wat je met de LiveCD kunt. Kortom; de LiveCD is alleen een 'bootstrap' voor ZFSguru. Als je eenmaal ZFSguru draait - hoe dan ook - kun je altijd een installatie draaien.

Maar jouw punt is: de normale manier van LiveCD pakken en installeren moet gewoon soepel werken. Mee eens! Maar kijk dan eens goed naar het laatste scherm dat je krijgt van de Welcome Wizard; daar wordt je duidelijk gewezen op de installatie. En er staan nog tips van misschien wil je vóór de installatie nog je SMART checken, enzovoorts.

[syl765]

Ok , ben even opnieuw begonnen en nu niet zo gehaast geprobeerd te installeren.
Als je goed leest word het allemaal wat makkelijker.
Toch nog wat zaken tegen gekomen.

Bij het maken van de pool het volgende geselecteerd.


Echter kan de pool niet gemaakt worden.


Selecteer ik modern dan lukt het wel, alleen dan dus spa 28 en inderdaad zoals je aangaf selecteer je Reduced dan zie je het spa nummer en zfs versie nummer veranderen.
Ik denk dat modern gewoon 5000 moet zijn, ook gezien het feit dat de zfsguru site de image aanbied als
Download ZFSguru with FreeBSD 9.2 and ZFS v5000 (recommended) waar v5000 dus als hoogste versie word aangegeven.

Dan de laatste pagina waarna het even zoeken was.

Hierna raakte ik de eerste keer dus de weg kwijt. nadat ik de recommended optie had gekozen.
Een extra regel bij die andere drie met iets als onderstaande tekst zou een hoop onduidelijkheid weg kunnen nemen.
Return to the installer: System -> install

Nog een klein detail.

Het filter aanpassen gaat niet.
Door het verversen van de pagina moet je wel heel snel kunnen typen.
Als je op de knop Use filter klikt kom je terug op de volgende pagina


Bij het aanmaken van gebruikers laat de GUI het wachtwoord zien, kan niet de bedoeling zijn!

Nou dat was het.
Excuses voor de vorige topics die dus niet allemaal terecht waren.

gr
johan

[Verwijderd]

syl765 schreef op dinsdag 14 januari 2014 @ 21:07:
Bij het maken van de pool het volgende geselecteerd.
[afbeelding]

Echter kan de pool niet gemaakt worden.

Ah, dat is een zpool issue, waarbij je wel versie 28 mag opgeven maar niet 5000, dat moet in een apart commando. Voor de Pools->Create pagina is dat aangepast, voor de Welcome Wizard nog niet, dat is inderdaad een bug.

Ik denk dat modern gewoon 5000 moet zijn, ook gezien het feit dat de zfsguru site de image aanbied als
Download ZFSguru with FreeBSD 9.2 and ZFS v5000 (recommended) waar v5000 dus als hoogste versie word aangegeven.

Ondersteuning voor de nieuwste features hoeft nog niet te betekenen dat het als default wordt gepromoot. In het verleden heeft ZFSguru ook altijd gezegd: begin laag met ZFS pool versie en upgrade alleen naar wat je nodig hebt, ipv gelijk de hoogste versie pakken en daarmee onnodig compatibiliteit verkleinen met andere platforms die enkel een lagere ZFS versie ondersteunen.

Wel vind ik dat dit beter uitgelegd moet worden, en de gebruiker moet natuurlijk ook gewoon voor v5000 kunnen kiezen; zoals ook kan op de Pools->Create pagina en voor de Welcome Wizard dient het ook aangepast te worden. Maar er kan wel uitleg bij dat het verstandig kan zijn hem nog op v28 te houden, zeker als je geen LZ4-compressie van plan bent te gebruiken, en je mogelijk nog wilt migreren naar andere platforms, zoals Nexenta. Ik noem maar wat.

Nog een klein detail.
[afbeelding]
Het filter aanpassen gaat niet.
Door het verversen van de pagina moet je wel heel snel kunnen typen.

Dan klik je toch eerst op de knop 'stop refreshing page' ?

Dit is vrij simpele functionaliteit; kan ooit vervangen worden door iets moois. Maar voor nu werkt het mits je wat behendig bent en gstat kunt lezen.

Als je op de knop Use filter klikt kom je terug op de volgende pagina

Hm dat zou een bug zijn, ik ga eens kijken!

Bij het aanmaken van gebruikers laat de GUI het wachtwoord zien, kan niet de bedoeling zijn!

Mwa voor het laagdrempelige van ZFSguru kan het fijn zijn om in elk geval de optie hebben om het wachtwoord te laten zien. Niet iedereen vind die sterretjes handig. Zo geef ik er ook weinig om; ik zie liever mijn wachtwoord. Bang voor afkijken hoef ik niet te zijn. In een bedrijfsmatige omgeving is dat natuurlijk heel anders. In elk geval moet de optie er komen of het een of het ander.

Excuses voor de vorige topics die dus niet allemaal terecht waren.

Excuses is natuurlijk niet nodig; logisch dat ik iets beter weet hoe het in elkaar zit dan iemand als jij die het even snel uittest.

Jouw bevindingen zijn ook heel waardevol. In elk geval twee bugs en feedback dat het laatste installatiescherm toch niet zo'n goed einde is. De Welcome Wizard en Installatie zouden iets beter moeten aansluiten. Dat soort dingen kunnen we wat mee.

Verder wel jammer dat drag&drop niet werkt voor Chrome, Safari en IE. Maar dat is misschien snel te fixen. Beta10 met 'GuruDB' is ook niet ver meer verwijderd. De Beta11 met Migration Manager is wel weer een grotere update. Daarna zou de RC kunnen komen (mogelijk met FireDrunk's daemon) en daarna final.

[FireDrunk]

De daemon is een hoop werk hoor, bedenk dat eigenlijk alles wat nu met sudo gedaan wordt met Python gedaan moet worden (of met bash wat afgetrapt wordt door Python w/e).

Dat is best een hoop werk.

[DXaroth]

Wat je eigenlijk wilt is python bindings voor zfs gebriuken; dat scheelt je constant nieuwe shells spawnen, maar de zfs bindings voor python zijn niet compleet (at best).

Bedenk je ook dat je niet alles in 1x hoeft te doen; zolang dingen in beweging blijven zal het veel makkelijker zijn voor de web interface bij te benen, ipv dat er een maand niks gebeurd, dan een complete api implementatie er is, dan een maand integratie aan de web kant, gevolgd door een nieuwe interface... op de eerste manier kan je ook veel makkelijker mensen dingen laten testen, zodat je bugs snel en efficient kan oplossen (voordat je dezelfde bug introduceert in andere gedeeltes)

[Verwijderd]

HmHm. Dat laatste is nu ook zo; de releases worden voornamelijk getest door de gebruikers zelf. Zo werkt in beta9 de drag&drop niet voor andere browsers dan Firefox. Dat kunnen we proberen op te lossen terwijl beta9 gewoon beschikbaar is. Dus ik ben opzich ook wel voor 'release early, release many'. Dat gezegd is het wel fijn als er een stable versie beschikbaar is, dat maakt het introduceren van regressions iets minder erg; als je een stabiel product wilt pak je de stable versie. Wil je de nieuwste features, dan pak je de experimental branch. Dat laatste is ook uitstekend voor bughunters.

Maar DXaroth, wat bedoel je precies met Python bindings voor ZFS?

[CurlyMo]

Verwijderd schreef op woensdag 15 januari 2014 @ 15:41:
Dus ik ben opzich ook wel voor 'release early, release many'.

Je moet niet doorschieten. Een drag & drop functie is prima te testen door jou als dev voordat het gereleased wordt.

Velen maken onderscheidt tussen:
Alpha
Beta (en/of Release Candidates)
Stable

of

Alpha
Stage
Stable

Ik gebruik:
Alpha --> github developmental branch
Devel --> via offficiele apt repo
Stable --> github / apt.

[DXaroth]

Python heeft de mogelijkheid om modules in te laden (deels net zoals php, maar dan in een efficientere manier), net zoals applicaties de mogelijkheid hebben om python in te laden (dus ja, letterlijk python als 'scripting engine' kunnen gebruiken voor je app/game/whatever).

Dit wordt veelal gebruikt als interface modules (MySQL, SSH, etc), waarbij je vanuit python dan een programmatische interface krijgt in de functies die uitgevoerd worden... dit wordt vaak ook bindings genoemd als het om libraries gaan.

in effect, krijg je dus het verschil tussen:

Python:

import subprocess 

output = subprocess.check_output("zfs list",shell=True)
processed_output = do_some_processing_here(output)

en

code:

import zfs

processed_output = zfs.list()

Niet alleen ziet dit er netter uit, de 'overhead' van een nieuwe shell spawnen om wat in te draaien wordt opeens merkbaar (stel je moet 30 commands uitvoeren, dan zit je dus in 1 call 30x een nieuwe shell op te bouwen, en af te breken)..
In plaats daarvan worden direct libraries aangesproken, en daarmee, direct zfs.


Nu zijn er al wat projecten geweest in de afgelopen jaren die python bindings voor libzfs werkend te krijgen, waarbij sommige dit best netjes aan de praat hebben kunnen krijgen.. het nadeel is, is dat veel hiervan niet (goed) onderhouden worden, waardoor ze dus niet (goed) met de nieuwe versies van libzfs kunnen compilen, waardoor je dus niet de juiste python module kan bouwen.

[Verwijderd]

@CurlyMo
ZFSguru heeft pas bij 0.2 een 'stable' willen releasen, omdat het pas dan als een af en bruikbaar product heeft geleid. Idee is dat 0.2 stable is terwijl we al met 0.3 bezig zijn. Bugs in 0.2 kunnen dan snel gefixed worden, terwijl 0.3 een work-in-progress is met regelmatige 'snapshots' van de development tree. Tot er een -beta en rc komt en daarna is 0.3 stable en 0.4 de development. Vrij simpel model, maar als dit werkt dan hebben we zowel een stabiele release met bugfixes als een branch voor mensen die toegang tot de nieuwste features wilt hebben.

Het is namelijk heerlijk om gebruikers als betatester te gebruiken, met name voor browserbugs. Ik weet verder niet met welke browsers getest had, maar in elk geval met Chromium en Firefox. Maar door aanpassingen door de tijd kan functionaliteit toch weer 'stuk' gaan.

Voordeel van nu al releasen is wel dat de rest van de functionaliteit al bruikbaar is terwijl wij bezig zijn de drag&drop voor meerdere browsers geschikt te maken. Belangrijker is dat bestaande functionaliteit niet kapot gaat, zogenaamde regressions. Dat vind ik erger dan nieuwe features die nog niet altijd goed werken.

@Dxaroth:
Dank voor je uitleg. Hoewel het inderdaad netter en sneller is, is het ook een extra afhankelijkheid. Met normale shell utilities heb je hier geen last van. De lagere efficiency kun je dan wellicht op een andere manier adresseren, zoals door background polling van bepaalde (ZFS) data of caching aan de web-interface zijde. Gevaar daarbij is cache poisoning, maar ik heb wat ideeën hierover.

[DXaroth]

Verwijderd schreef op woensdag 15 januari 2014 @ 17:23:
@Dxaroth:
Dank voor je uitleg. Hoewel het inderdaad netter en sneller is, is het ook een extra afhankelijkheid. Met normale shell utilities heb je hier geen last van. De lagere efficiency kun je dan wellicht op een andere manier adresseren, zoals door background polling van bepaalde (ZFS) data of caching aan de web-interface zijde. Gevaar daarbij is cache poisoning, maar ik heb wat ideeën hierover.

Dependencies boeit an-sich niet -zo- erg, het is een extra package die je moet installeren.. de dependencies heb je toch al (want je hebt libzfs nodig voor zfs-interactie zelf).

Hetzelfde geld voor caching; als je caching gaat toevoegen, moet je er iets bij wat dat efficient kan doen (memcached, redis, whatever).. dat zijn ook weer extra packages (en begrijp me niet verkeerd, memcached is een van de eerste dingen waar ik tijd aan besteed om dat 'netjes' te laten werken met mijn webapps, omdat het gewoon super nuttig is).. dus ook dependencies... dus hoe dan ook ga je aan extra packages komen.

Extra packages is ook niet per se verkeerd; als je dit simpel kan installeren, dan ga je er ook geen last van hebben.. het enige vereiste is dat je packages gebruikt die goed onderhouden worden, tenzij je dit zelf wilt gaan doen

[Verwijderd]

Met afhankelijkheid bedoelde ik afhankelijkheid van een derde partij om die bindings in sync te houden met libzfs. Als je via de shell aanroept heb je daar geen problemen mee, omdat de shell utilities (zfs/zpool) natuurlijk goed kunnen parsen.

In de ZFSguru web-interface wordt op dit moment al beperkte caching gebruikt; voor sommige functies die meerdere keren binnen eenzelfde pageview worden aangeroepen, en voor het cachen van remote files. Dat laatste wordt in de config dir weggeschreven: config/cache.bin.

[CurlyMo]

Waar blijft die reactie?

[Verwijderd]

Als je bedoelt de brief naar Jason, die heb ik al bijna klaar. De reactie naar jou toe is zo lang geworden dat ik er even mee ben gestopt. Wellicht beter om alle punten samen te vatten en dat naar Jason toe te sturen.

Ik heb het alleen heel erg druk; morgen zou op zijn vroegst kunnen.

[CurlyMo]

Het ging om de reactie naar mij toe waarvan je zelf meerdere keren aangaf dat je die zou gaan geven.

[Verwijderd]

Maar in de tussentijd is de discussie voortgegaan en heb ik ook al een deel van de punten in mijn reactie behandeld. Een enorme lap tekst posten waarvan ook de helft al is behandeld, lijkt me nu niet de juiste actie. Misschien beter om het meteen heel concreet te maken en er een conceptbrief richting Jason van te maken, met alle belangrijke punten die in deze discussie genoemd zijn.

Zo dacht ik in elk geval. Want een klerelange reply en weer deel 2 van de discussie heb ik ook niet zo heel veel zin in. Het is ook redelijk duidelijk wat de punten zijn in dit topic. Dus misschien leuker om dan concreet wat resultaten te boeken en dan wellicht in februari/maart te kijken wat er van terecht is gekomen. Eventueel kan dan een grotere discussie komen als duidelijk is dat Jason en ik jullie zorgen en wensen ook serieus nemen.

Of wil je toch dat ik dat monster plaats? Ondanks dat ik er veel tijd aan heb besteed is hij ook nog lang niet af.

[CurlyMo]

Stuur anders hetgeen je tot nu toe geschreven hebt naar mij via de DM, dan weet ik wat de strekking van je reactie tot nu toe is. Dan haal ik het uit mijn hoofd als iets wat ik nog moet lezen

[ Voor 27% gewijzigd door CurlyMo op 18-01-2014 16:45 ]

[FireDrunk]

Ik ben stiekum ook wel beniewd

[CurlyMo]

[Verwijderd]

Sorry sorry... ik heb het enorm druk gehad afgelopen dagen. Maar vanavond heb ik 'vrij' dus prima moment om mijn belofte aan jullie in te willigen.

Kortom, vanavond morgen ga ik zeker reageren!

[ Voor 4% gewijzigd door Verwijderd op 23-01-2014 03:07 ]

[Room42]

Ik moet zeggen dat ik de user interface van ZFSguru bijzonder prettig vind! Jammer dat ik het 'nu al' ontdekt heb, omdat het nog niet volwassen genoeg is, maar qua ZFS-beheer ben ik zeer te spreken. De zaken eromheen (de NAS-achtige services, gadgets, hebbedingetjes, zoals ik ze zie.) boeien me minder.

[Rikkiz0r]

Verwijderd schreef op woensdag 22 januari 2014 @ 18:32:
Sorry sorry... ik heb het enorm druk gehad afgelopen dagen. Maar vanavond heb ik 'vrij' dus prima moment om mijn belofte aan jullie in te willigen.

Kortom, vanavond morgen ga ik zeker reageren!

Ondertussen zijn we twee dagen verder en ben ik toch wel benieuwd

[dylanvana]

Ziet er leuk uit en erg handig voor leken! Snap alleen niet dat Jason dit een OS durft te noemen. Dit is gewoon software en geen OS. FreeBSD is de OS, ZFSGuru is de software die het mogelijk maakt door FreeBSD! Die gradient overlays zijn imo echt not done in 2014. Alsof het zijn eerste Photoshop projectje is

[CurlyMo]

Verwijderd schreef op woensdag 22 januari 2014 @ 18:32:
Sorry sorry... ik heb het enorm druk gehad afgelopen dagen. Maar vanavond heb ik 'vrij' dus prima moment om mijn belofte aan jullie in te willigen.

Kortom, vanavond morgen ga ik zeker reageren!

Het schets wel waarom dat jij en Jason zo'n goede synergie hebben

[Dadona]

Nou, op synergie wil ik het niet gooien, hooguit selectiecriterium.

Maar even voor nu, hoe gaat dit alles nu verder? Is dit nu een, even beide kanten het verhaal laten doen en we gaan weer verder? Moet de discussie simpelweg op zfsguru.com plaatsvinden (meteen Engelstalig, handig voor Jason)? Komen er concrete actiepunten?

[FireDrunk]

En inmiddels is het zondagvond....

[Verwijderd]

Hè.. net dat ik al mijn taakjes klaarheb.. worden ze hier ongeduldig..

Maar jullie hebben helemaal gelijk, de tijd van vooruitschuiven is nu voorbij!

[HyperBart]

Dus vandaag, maandag, mogen we het verwachten?

[FireDrunk]

Die reply is onderhand een Bijbel joh!

[Verwijderd]

Nou, het grappige is dat er wel zoiets als een oud testament (mijn oude reactie naar CurlyMo) als een nieuw testament (nieuwe inzichten) is, dus je analogie is zo gek nog niet.

Maar nog even geduld; denk dat het niet tegen zal vallen.

[sphere]

Even afgezien van wat er eventueel allemaal mis is met ZFSguru: na het installeren van vanilla FreeBSD 10 snap ik de behoefte wel aan een FreeNAS of ZFSguru, tot voor kort kende ik dit niveau van gebruikershaat nog slechts van distributies als slackware.

[FireDrunk]

Hahaha, hoe komt het?

Hier was het gewoon, Root-on-ZFS (Experminetal), Optie, Optie, Enter, Enter, Reboot.

Of bedoel je daarna?

[sphere]

Ik bedoel: een package manager die je een pakket laat installeren en vervolgens tussen neus en lippen door laat weten dat je zelf nog procfs moet fixen en allerlei randzaken voor je KDE kan draaien.

[FireDrunk]

Oh, grafische shit, ja daar is FreeBSD ook niet voor joh

/sarcasm

[Dadona]

Zou je deze topic als het script voor een western film zien dan zou dit deel van het topic de scene markeren waarin je een wide-shot te zien krijgt met een statische achtergrond, met een overtrekkende dunne stofwolk en de welbekende tumbleweed in de voorgrond.
...and cut!

[Verwijderd]

Stilte voor de storm?

[CurlyMo]

Verwijderd schreef op woensdag 29 januari 2014 @ 22:31:
Stilte voor de storm?

Dit is wel tekenend voor mijn punt hoor. Vele releases betreft niet alleen code, maar ook communicatie.

[EnerQi]

CurlyMo schreef op donderdag 30 januari 2014 @ 00:14:
[...]

Dit is wel tekenend voor mijn punt hoor. Vele releases betreft niet alleen code, maar ook communicatie.

En misschien het grappige (of juist trieste) stukje maar juist dit topic geeft aan dat er iets schort aan de communicatie.

Of de verwachtingen zijn sky high of een deel heeft opgegeven

[FireDrunk]

Ik denk dat laatste....

[Room42]

En dat laatste is natuurlijk ook geen punt, als het de kwaliteit van de rest van het project ten goede komt.

Maar ik vrees dat CiPHER zich klemgepraat heeft door een uitgebreide reactie toe te zeggen en daar nu flink tegenop ziet. Maar dat is mijn invulling. Ik kan het me alleen wel voorstellen omdat ik dat soort dingen ook wel eens doe

[ Voor 13% gewijzigd door Room42 op 30-01-2014 17:48 ]

[Verwijderd]

Ik heb mijn best gedaan goed te communiceren in dit topic. Valt ook niet mee één iemand tegen een dozijn anderen. Daarnaast, besef ajb dat ik het ook druk heb met andere dingen.

Dat gezegd, jullie hebben je punt gemaakt; de bal ligt nu bij 'ons'. Mijn idee was eerst een reactie op CurlyMo en een brief naar Jason, maar in de tussentijd heb ik al met Jason gepraat en daar is veel uit voortgekomen. Nu heb ik vanavond nog een gesprek. Ik hou niet van deadlines maar ik hoop morgen de 'endgame' in te zetten wat betreft dit topic. Mogelijk vanavond al meer openheid over hoe Jason en ik aankijken tegen de voorstellen en inzichten.

Dus het verzoek, heb nog even geduld? Ik doe mijn best, ook tussen alle verplichtingen van het echte leven door.

[CurlyMo]

Doe dan geen beloftes, scheelt al een hoop gezeur.

[Verwijderd]

Een toezegging cq. voorspelling is geen belofte.

[CurlyMo]

Als dat je manier van communiceren gaat worden met een toekomstige community...

[DXaroth]

Verwijderd schreef op donderdag 30 januari 2014 @ 18:36:
Een toezegging cq. voorspelling is geen belofte.

Noot: dit is geen rant, dit is hopenlijk informatief..ish..


Toezegging schept verwachting; niet nakomen van de verwachting (ook al was het niet een 'afspraak' of een 'belofte' ) geeft een negatieve perceptie.

Als je gezien wilt worden als een community manager (wat je doet door 'names zfsguru' met ons een discussie aan te gaan), dan is het handig om dat in je hoofd te houden; wat jij bedoeld met je posts zal niet altijd zijn wat de andere kant gaat lezen.

Nu boeit het mij persoonlijk geen drol, want ik ben geen ZFSguru gebruiker (enkel geinteresseerd in ZFS waarbij ik hoop dat projecten als ZFSguru ervoor zorgen dat ZFS beter gesupport wordt), maar ik kan me indenken dat mensen niet al te positief zullen zijn als je weken lang zegt dat je er mee bezig gaat, en het 'binnenkort' af zal hebben, en dan niets laat horen.

Zeg dan gewoon: joh, dit duurt nog wel een paar weken.. dan ben je realistischer, en zullen mensen je er niet zo snel op veroordelen (mits je natuurlijk wel probeert om het binnen die 'paar weken' af te hebben)

[Verwijderd]

Ik snap je punt en het is goed om realistisch te zijn en voor zoveel mogelijk te voorkomen dat er valse verwachtingen worden gewekt. Maar aan de andere kant, het leven loopt zoals het loopt. Er zijn ontwikkelingen geweest die mijn reactie weer uitstelden. Past ook binnen de BSD releaseschema's: it's done when it's done. Dus als er staat 1 februari kun je denken aan maart/april, en eind februari als het mee zit. Dat is ook de insteek van de nieuwe roadmap op de nieuwe website trouwens; daar staat 'op zijn vroegst' dus het meest optimistische scenario, met de duidelijke noot dat het zeer waarschijnlijk is dat alles opschuift. Maar dan zie je wel in welke volgorde het opschuift. Derhalve biedt het wel zekerheid op welke feature je wacht.

Community Manager heb ik ook echt geen tijd voor. Maar in deze discussie is de term voor een vacature gevallen en moderators op het nieuwe forum, dus hopelijk komt dat vanzelf.

[Verwijderd]

*** Het Oude Testament ***

[Verwijderd]

Het Oude Testament

---

Genesis

In the beginning Jason created the Project.
And the Project was without form. The Spirit of Jason moved upon the face of the waters.
And Jason said, let there be light: and there was light.
And Jason saw the light, and it was good.

Nee zonder gekheid, het is wel leuk om even bij het begin te beginnen. Hoe is ZFSguru precies ontstaan? Op het HardOCP forum ontstond een discussie dat ZFS op Solaris/FreeBSD te ingewikkeld is voor veel mensen om als NAS te gebruiken. Iedereen daar gebruikte dure Hardware RAID en keken neer op ZFS als een gekkigheid wat alleen op lijpe OS draait als Solaris en BSD, en niet Linux en Windows waar de zogenaamde Hoge Heren zich comfortabel bij voelden. Als bewijs dat BSD+ZFS ook voor doorsnee gebruikers inzetbaar is, maakte Jason een proof-of-concept met een paar .php scripts om disks te tonen, ze te formatteren en een ZFS pool aan te maken. Later kwam er de mogelijkheid bij om Samba shares te maken. Et voila, zo hebben we een start van een bruikbaar project.

Pas later dat Jason serieus werk ging maken van ZFSguru, met een aantal rewrites van het hele project tot gevolg. Maar Jason had meer ideeën dan een simpele web-interface. Hij wilde een project wat heel laagdrempelig is zodat heel veel mensen ZFS kunnen benutten. Mede hierdoor is de eerste stable release telkens uitgesteld en zijn er andere 'leuke' features gekomen, terwijl de basisfunctionaliteit nog niet helemaal was afgebouwd. Zo mist ZFSguru tot op dit moment nog steeds de Migration Manager, een essentiëel onderdeel van ZFSguru volgens de opzet van Jason. Dit maakt het wisselen tussen systeemversies veel makkelijker doordat je controle hebt over de configuratie die je meeneemt naar de nieuwe installatie. Desondanks heeft de 'detour' wel een aardig kijkje gegeven in de toekomst van ZFSguru; ambities voor méér dan slechts een web-interface voor ZFS. Ook extra functionaliteit moet makkelijk te installeren en te gebruiken zijn. Maar ook gebruikers die deze functionaliteit niet willen, worden bediend door de modulaire opzet, zodat zij niet de 'bloat van een ander' hoeven te draaien.

Achter de schermen is de serveropzet regelmatig gewijzigd, zijn de buildscripts door evoluties verfijnd en hebben we inmiddels plannen voor automatische builds. Dat is nodig zodat de aandacht kan naar het daadwerkelijk verbeteren van de services en de andere delen van het ZFSguru project.

---

The Fall of Man

Maar Jason is soms ook roekeloos, want door de vele aandacht aan ZFSguru kwam hij in geldproblemen en moest noodgedwongen verhuizen en nog wat dingen waardoor hij een tijdje niet aan ZFSguru kon werken. Onhandig als hij is, heeft hij dat ook niet goed gecommuniceerd. Daar is vervolgens veel kritiek op gekomen, omdat mensen een eenmansproject niet levensvatbaar achten. Toen ik steeds meer betrokken raakte bij ZFSguru heeft Jason mij als extra developer aangesteld, maar daarmee is de kern van het probleem nog niet opgelost.

De strategie van Jason was om eerst de basis van ZFSguru te ontwikkelen en daarna de rest van het project. Pas als de motor goed is, moet je de auto bouwen, zoiets.

Want: zodra een grotere mensenmassa ZFSguru gaat gebruiken moet alle infrastructuur ook gereed zijn. Als dan opeens de serverinfrastructuur op zijn bek gaat omdat dit nog niet goed geregeld is, dan is dat natuurlijk een doodzonde. Het gevolg van al deze 'infrastructuur' en werk achter de schermen is wel dat de eerste stabiele release - 0.2 - nog steeds niet is verschenen. Dit terwijl er al werk is verzet voor de 0.3 netwerkfeatures, en veel andere ideeën al in het schetsboekje van Jason staan.

Wat Jason namelijk nog niet geregeld heeft, is de licentie en opzet van het project. De naam 'community project' is in deze discussie voorbij gekomen, maar daar is vooralsnog geen sprake van in die zin dat er slechts sporadisch code wordt gesubmit afgezien van Jason en ik.

---

De Zondvloed

En toen ik op oudejaarsavond de toekomst van ZFSguru besprak hier op Tweakers, kwam ik onder vuur te liggen en vertelde iedereen wat er mis was of ontbrak aan ZFSguru in zijn huidige vorm. Hierop heb ik het initiatief genomen om een speciaal topic aan te maken, om alle kritiekpunten inhoudelijk te behandelen.

Dat is ook uitgebreid gebeurd, waarbij het voor mij soms behoorlijk tijdrovend en intensief was om meerdere mensen tegelijk van antwoorden te voorzien; voor mijn gevoel was het soms 7 versus 1.

---

De Ark van CurlyMo

Maar tussen de redelijke en soms ook iets minder redelijke gesprekken door, is er één post die in het bijzonder mijn oog trok; de reply van CurlyMo. Zoals zo vaak begonnen aan een quote-reply, maar tussendoor ging de discussie door en kreeg ik de reply niet af. Sommige dingen heb ik al verteld tijdens de discussie daarna, die ik eigenlijk in de brief wilde hebben. Kortom, net als Jason doe ook ik dingen verkeerd.

Maar ondanks dat ik de indruk krijg dat jullie de voortgang van de discussie niet zo positief inzien (klopt dat?) denk ik dat er wel degelijk veel is bereikt. Zo heeft CurlyMo mij overtuigd van de enorme kracht van de groep, ook al in een vroeger fase van het project. Vooral het punt dat na het beschikbaar stellen van de 'tools' die je nodig hebt om bij te dragen, de contributies vanzelf komen en zoiets ook kan uitgroeien. Maar ook de lol van snelle ontwikkeling van een project. De kracht van de massa is enorm en waar CurlyMo mij vooral in heeft overtuigd is dat ZFSguru op dit moment veel kansen laat liggen om mensen te binden die eventueel bij zouden willen en kunnen dragen aan het project.

Jason wilde die stap pas maken nadat alles 'gereed' was. Zoals Jason het voor ogen had met een geïntegreerde bugtracker, in-game help zoals iemand dat zo leuk noemde, community messages (priveberichten tussen ZFSguru gebruikers) en ZFSguru bulletins - communicatie van de developers aan de gebruikers. Maar ook de addon service waarmee je zelf services kon maken, of vertalingen in de toekomst.

Maar de termen 'Not Invented Here' vielen al snel tijdens de discussie; Jason zou teveel zelf willen doen en in ogen van sommigen ook het wiel opnieuw uitvinden en daarmee kostbare ontwikkeltijd verspillen. De grap is wel dat dit concrete voorbeeld de eigen mini-webserver betrof die gedurende de discussie van het project ook daadwerkelijk is gebouwd middels een proof-of-concept door FireDrunk. Kennelijk is niet zozeer de wens om zelf dingen te ontwikkelen niet cruciaal, maar meer de communicatie, aansturing maar vooral ook de betrokkenheid van de rest van de community cruciaal. Pas als genoeg mensen ZFSguru een interessant platform vinden, willen zij hun tijd in het project steken.

In die zin ben ik dus opgeschoven dat het snel werkend krijgen van een basis infrastructuur om contributies te vergemakkelijken, een goede stap zou zijn. Ook heb ik er zelf wel zin in gekregen om met een grotere groep te ontwikkelen. Op dit moment laat ZFSguru kansen liggen op gebied van vooruitgang.

---

De Brief aan Jason

Daarop was ik bezig met een Brief aan Jason waarin ik alle punten uit de discussie zou verwerken en dan hier zou posten, vervolgens aan Jason zou laten lezen. Maar dat is natuurlijk ook weer anders gelopen; ik heb met Jason zelf al een paar lange avonden gesproken over de toekomst van ZFSguru en zijn rol daarin. Dit maakt de brief overbodig. Het gevolg is een totale herziening van het project.

[CurlyMo]

Graag gedaan. Zodra die infrastructuur er is, zal ik eens wat van mijn code bijdragen in plaats van het lokaal te houden. Mijn voorkeur gaat uit naar git.

[FireDrunk]

Ik wil echt niet weer de flameboer uithangen, maar je schrijft nu 2 A4tjes vol met redenen en maar's, en dit en dat.

Maar wat nou juist *ECHT* belangrijk is, zeg je weer eens niet? Waarom wil je niet vertelen wat Jason's reactie was? Als je hele avonden hebt zitten babbelen, zal er genoeg stof zijn die hier nogmaals opgeschreven kan worden (zij het verkort uiteraard )

Kortom: Je communiceert wel, maar je draait om de hete brij heen..

Om CurlyMo aan te vullen: Waar blijft GIT, waar blijft Redmine, waar blijven de build scripts, en waar blijft de roadmap update?

En kom niet aan met dat je die vragen niet kan beantwoorden, want het is gewoon een simpel: Ja dat gaan we doen, of Nee dat doen we niet...

[EnerQi]

Dus als er staat 1 februari kun je denken aan maart/april, en eind februari als het mee zit. Dat is ook de insteek van de nieuwe roadmap op de nieuwe website trouwens; daar staat 'op zijn vroegst' dus het meest optimistische scenario

Alsjeblieft doe dit niet.... Hierop word je afgerekend en dat is juist wat je niet wilt hebben. Je kunt dus beter de roadmap uitleggen en vervolgens niet aangeven wanneer er iets aanwezig zal zijn. Door datums te noemen schep je verwachtingen .

Maar wat nou juist *ECHT* belangrijk is, zeg je weer eens niet? Waarom wil je niet vertelen wat Jason's reactie was? Als je hele avonden hebt zitten babbelen, zal er genoeg stof zijn die hier nogmaals opgeschreven kan worden (zij het verkort uiteraard )

Ik denk dat FireDrunk het helder verwoord hoe de meeste mensen denken . Er staat nog steeds niet in WAT er nu gaat veranderen. Het doet me wel deugd dat men wil veranderen

[ Voor 31% gewijzigd door EnerQi op 02-02-2014 22:05 ]

[Verwijderd]

Er staat nog steeds niet in WAT er nu gaat veranderen.

Dat is ook onderdeel van Het Nieuwe Testament, maar dat komt nog.

Ik dacht, alvast het eerst deel verfijnen en posten, kan ik bezig gaan met het tweede deel verfijnen en daarna posten.

Kortom, geduld.. geduld.. ik was allereerst benieuwd naar de reacties over het deel wat ik al heb gepost.

[Verwijderd]

*** Het Nieuwe Testament ***

[Verwijderd]

---

Het Nieuwe Testament

---

Het offer

Om onze gebruikers - de Goden - tevreden te stemmen, moet er geofferd worden. De goden hebben opgedragen:

1. Betere communicatie over het project richting de gebruikers.
2. Wiki voor gebruikers om informatie te delen.
3. Bugtracker voor melden en tracken van bugs.
4. Publieke repository voor het volgen van de development branch en submitten van contributies.

Het offer aan de goden:

1. Ter bevordering van de communicatie:
a) nieuwe website met up-to-date (dynamische) informatie; Maart 2014
b) documentatie over de werking van ZFSguru under-the-hood; Maart 2014.
c) vacature voor 'Community Officer' en wellicht ook moderator op het nieuwe forum.
2. Wiki kan online zodra de nieuwe server er is (maart). Login heb ik ook al een idee over om dat veilig te syncen. Maart 2014.
3. Bugtracker kan Redmine worden en met synced login zoals bij de wiki. Maart 2014.
4. Repository kan online nadat besloten is over de licentie en over zelf hosten of iets als freshports/github gebruiken. Streefdatum: zomer 2014.

---

King of My Castle

Behalve deze concrete punten vind ik de grootste winst dat ik met Jason twee keer een lange avond heb gehad en goed hierover heb gepraat. Onder meer over het met een team werken aan ZFSguru. Jason zag eerst veel bezwaren, maar gaandeweg de discussie zijn we denk ik beide opgeschoven. In die zin, dat hij heeft geschetst dat in principe overal aan gewerkt kan worden, mits hij niet de controle verliest over de kern van ZFSguru. Hij wil zelf alles kunnen begrijpen en weten van de kern van ZFSguru. Addons zoals services zijn minder strict; daar gaat het enkel over dat er geen 'rogue committers' komen die malware in addons stoppen.

Concreet wil Jason dat alle beginnende committers hun werk eerst door Jason laten verifiëren, en pas na een testperiode als 'normale' developer - zoals ik - worden aangesteld. Dan kunnen ze in principe overal aan werken, net als ik dat doe, alleen stem ik natuurlijk wel goed af met Jason.

Ik moet wel zeggen dat Jason het niet makkelijk vindt om 'zijn project' los te laten in die zin dat meer mensen er over beslissen, want daar komt het op neer als we deze route volgen. Ik heb daar tegenovergesteld dat hij de kern van ZFSguru goed kan verifiëren, zodat het geen chaos wordt waardoor hij niet meer als zijn project ziet. Bovendien kan hij de knoop doorhakken omtrent development issues, mocht er een verschil in inzicht ontstaan. Dat is niet onredelijk denk ik, en daarmee is de vraag over leiderschap ook duidelijk geregeld. En invloed op dat leiderschap is er zeker, mits je goede argumenten en voorstellen hebt. Ik merk vooral dat Jason zijn eigen ambities wil blijven kunnen waarmaken, en dat zie ik niet in strijd met meer betrokkenheid van buitenaf. Mits we het goed regelen...

Je zou kunnen stellen dat jullie mij hebben overtuigd - in elk geval voor een belangrijk deel - en ik vervolgens Jason heb overtuigd. Zo kunnen ook gelijk alle verhalen over mij als 'knecht' van Jason de wereld uit geholpen worden. Heerlijk als dingen zo mooi samenlopen.

---

De transformatie: Mesa

Dat gezegd, hebben we wel een tijdspad besproken. Het idee is dat na 0.2 - wat al redelijk snel is, van de zomer - de integratie met Mesa gaat plaatsvinden. Dat zal een mooi begin zijn van de infrastructuur voor contributie, zodat Mesa als modulair platform gaat dienen en ZFSguru als 'Plugin' hierop aanhaakt. Zo kunnen ook andere onderdelen modulair worden ontwikkeld onder dezelfde paraplu. De Wiki en Bugtracker kunnen al op korte termijn gerealiseerd worden. Ook kan binnen een maand de documentatie online komen over de structuur van ZFSguru. Tot die tijd handmatig submitten via email/forum is prima te doen.

Mesa gaat een hele belangrijke rol spelen bij de Community Interaction binnen de ZFSguru web-interface. Jason heeft 'newforum' bedacht qua schetsen en wil dat binnen Mesa implementeren. Zowel de publieke website als de ZFSguru web-interface krijgen beschikking hierover en kunnen zo probleemthreads over b.v. services of specifieke pagina's 'renderen' dankzij dezelfde gedeelde code, waarbij de data binair wordt aangeleverd via het netwerk. Daarbij wordt dezelfde structuur gebruikt als GuruDB, wat in beta10 alle remote database downloads integreert in één downloaded en compressed file.

Het uiteindelijke idee is dat ZFSguru een platform wordt waarbij je heel laagdrempelig hulp kunt zoeken van mensen die 'online' zijn en je kunt daarbij ook heel specifiek aangeven waar je eventueel bij wilt helpen, of juist helemaal niet. Het idee is dat het leuk wordt om andere mensen te helpen, en je hier ook beloond mee kunt worden met iets wat zichtbaar is bij je avatar.

Je kunt een eigen 'wiki' webpagina hebben met publiekelijk beschikbare informatie zoals tips over dingen die je zelf hebt opgezocht voor ZFSguru of diens services.

De truc is dat alle informatie heel gericht te vinden is. Op de pagina voor Pools->Create zal de help pagina vooral gaan over optimale ZFS pool configuraties en op de System->Install pagina zullen vragen over nieuwe installaties/upgrades gesteld worden. Ben je een nieuwe gebruiker en kom je op een bepaalde pagina, kun je snel het 'beste' advies vinden dankzij 'newforum' wat heel duidelijk informatie geeft over problemen en oplossingen, in een minimalistisch maar stijlvoor vormgegeven gestructureerde forumstijl.

Op basis van de tools die je binnen ZFSguru krijgt, kun je zelf meewerken aan ZFSguru en ook direct online submitten. Dit zal alle functionaliteit van bugtracker,wiki,repo uiteindelijk overnemen. Maar tot het zover is, kunnen we terugvallen op de 'oude tools'.

---

De Grote Toekomst

Maar nu heb ik nog niets verteld over alle grote plannen, die ook hierop inhaken. Het is vrij duidelijk dat wij twee alleen dat nooit gaan klaren; de ambities liggen zéér hoog. Maar de strategie is om een interessant beginplatform te maken en daarop een fundering te bouwen wat de overige projecten gaat ondersteunen. We spreken hier over jaren in de toekomst; waarbij ZFSguru al is uitontwikkeld als ZFS interface. Nu al is ZFSguru vrij compleet qua ZFS ondersteuning dus tegen die tijd is het zo'n beetje af.

Dan verlegt de blik zich naar de overige projecten. Om die te realiseren zal een grote community nodig zijn. Daarover hadden Jason en ik het idee dat we 'schetsen' maken wat voor ideeën er zijn en je als coder zelf kunt kiezen voor zo'n schets en een beginimplementatie kunt maken, wat uiteindelijk kan uitgroeien to een bruikbaar iets. Zo kan Jason zich meer met ontwerp en minder met implementatie bezighouden -- een kenmerk waarbij de Developer zich onderscheid van de Coder.

---

Paradijs

Vrede op Aarde. Assad achter tralies, Poetin in een homobar, Wilders naar een asielzoekerscentrum. ZFSguru naar nieuwe hoogtes. Mooie plannen voor de toekomst. Fijnheid blijheid, ofzoiets.

[FireDrunk]

Ok, allemaal duidelijk, bedankt

Wel vraag ik mij af, waarom moeten sommige dingen toch zo lang duren? Ok, je hebt een dayjob, maar dannog. Maart 2014 voor het opzetten van Redmine? Kom op, 2 maanden om een next->next->finish te doorlopen?

Als je zegt dat je te weinig tijd hebt, hoe wil je dan in vredesnaam alle code gaan reviewen van mensen die straks gaan commiten? Dat kost je dan nog veel meer tijd, en heb je helemaal geen tijd meer over om zelfs iets te doen?

[CurlyMo]

Verwijderd schreef op zondag 02 februari 2014 @ 22:59:
Concreet wil Jason dat alle beginnende committers hun werk eerst door Jason laten verifiëren, en pas na een testperiode als 'normale' developer - zoals ik - worden aangesteld. Dan kunnen ze in principe overal aan werken, net als ik dat doe, alleen stem ik natuurlijk wel goed af met Jason.

Hier ga je naar mijn idee de mist in. Veel comitters hebben helemaal niet de behoefte om een "normale developer" te worden. Ze willen gewoon zo nu en dan nieuwe features of bugfixes doen. Zoals het hoort te gaan is als volgt:
Voorbeeld: https://github.com/pilight/pilight/pull/59
1. Gebruikers doen een "pull request".
2. Als admins krijg je een mail.
3. Vervolgens gaan zij de code doorspitten en testen:
https://github.com/pilight/pilight/pull/59.patch
4. Wanneer er veranderingen moeten komen, wordt dit met de submitter besproken, net zolang totdat de admins tevreden zijn.
5. De code wordt gemerged en de submitter wordt bedankt.

Ik moet wel zeggen dat Jason het niet makkelijk vindt om 'zijn project' los te laten in die zin dat meer mensen er over beslissen, want daar komt het op neer als we deze route volgen.

Daar komt het dus niet op neer. Je blijft zelf beslissen wat er gebeurt en welke richting je op gaat. Je geeft alleen de community de keuze om bijdragen te doen.

Daarover hadden Jason en ik het idee dat we 'schetsen' maken wat voor ideeën er zijn en je als coder zelf kunt kiezen voor zo'n schets en een beginimplementatie kunt maken, wat uiteindelijk kan uitgroeien to een bruikbaar iets. Zo kan Jason zich meer met ontwerp en minder met implementatie bezighouden -- een kenmerk waarbij de Developer zich onderscheid van de Coder.

Onderschat de eigenwijzigheid van gebruikers niet. Het is niet zo dat zodra je een community project wordt dat je gratis personeel hebt. De gebruikers komen zelf met mooie ideeën waar je niet aan gedacht hebt. Eventueel kan je direct mensen vragen dingen bij te dragen. Zo jou je mij kunnen vragen mijn webserver om te bouwen als je ziet dat ik ZFSguru gebruiker ben en in pilight een mooie implementatie heb zitten. Je ziet vanzelf dus mooie ideeën verschijnen. Vanuit mij kan je bijv. een mooie auto snapshot scripts verwachten of controle scripts met mail functionaliteit via gmail.

[Verwijderd]

@Firedrunk:
Nee, in maart zou de server online moeten zijn en geconfigged. En ik heb ook eind februari op de planning staan, maar het zal denk ik wel iets langer duren voordat het allemaal draait. Ik moet de hardware nog bouwen en een colocator zoeken in Amsterdam.

Mocht het echt langer duren, heb ik een alternatief met jailed wiki/redmine. Maar ik doe liever geen dubbel werk als minder dan een maand erna al een opvolger komt natuurlijk. Het is niet zo heel erg dat het anderhalve maand duurt voordat de infrastructuur op orde is? Ik zit meer te denken over daarna...


@CurlyMo:
Wat jij beschrijft is toch niet anders dan ik bedoel? Met het verschil dan dat, regelmatige committers die een interesse krijgen om meer te doen, uiteindelijk committer kunnen worden zonder approval van Jason voor elke commit nodig te hebben.

Ook mag je als committer veel zelf beslisen, maar bij meningsverschil met Jason over de ZFSguru/Mesa kern (de 'core') zal Jason de knoop doorhakken. Lijkt mij vrij logisch. Dat gezegd, de modulaire opzet zal betekenen dat veel commits zich op addons richten en de kern van ZFSguru minder commits krijgt. Dat is niet erg.

En mooie ideeën van gebruikers is prachtig! Zou mooi zijn als zij zelf helemaal hun eigen service met hun 'app' kunnen maken, zonder veel tussenkomst. En submitten naar de centrale database en huppa hij staat online. Dat geeft ook voldoening dat je iets hebt bijgedragen wat concreet zichtbaar is en waar jouw eigen naam aan verbonden is.

[Midas.e]

Waarom pak je eigelijk niet gewoon een VPS met freebsd erop? scheelt je zoeken naar een coloboer en hardware schrapen. Later kan je dat altijd nog doen zodra je meer resources nodig hebt.

[DXaroth]

Verwijderd schreef op zondag 02 februari 2014 @ 22:59:
Het offer aan de goden:

1. Ter bevordering van de communicatie:
a) nieuwe website met up-to-date (dynamische) informatie; Maart 2014
b) documentatie over de werking van ZFSguru under-the-hood; Maart 2014.
c) vacature voor 'Community Officer' en wellicht ook moderator op het nieuwe forum.
2. Wiki kan online zodra de nieuwe server er is (maart). Login heb ik ook al een idee over om dat veilig te syncen. Maart 2014.
3. Bugtracker kan Redmine worden en met synced login zoals bij de wiki. Maart 2014.
4. Repository kan online nadat besloten is over de licentie en over zelf hosten of iets als freshports/github gebruiken. Streefdatum: zomer 2014.

Niet om het een of ander, maar je wilt veel te veel in 1 klap (ook al is het een klap van 6 maanden).

Mijn tip: laat redmine voorlopig lekker vallen.. je hebt niet direct project management en al dat gezeik nodig.. dat kan eventueel later bij de 2e klap.. zoals al meermaals is gezegd, infrastructuur eerst.

Dat gezegd hebbende:

Begin met github. Deze stap alleen gaat al 3,5 van je punten in 1 snelle stap voorzien, namelijk:

• Repository
• Bugtracker
• Wiki
• Documentatie (de 0,5, want wiki is deels documentatie)

Zodra dit eenmaal in werking is (en dit zal even duren, dat ben ik zeker met je eens), en iedereen er rustig mee kan werken (wat ook wel even zal duren), kan je gaan denken over project management... want dat voegt niet ontiegelijk veel meer toe dan wat github uit zichzelf al aanbied.
En doe dan iedereen een plezier, en maak een team aan om alle zfsguru repositories aan te hangen.. het staat gelijk professioneler (zfsguru/<repository naam> vs <random gebruiker>/<repository naam> ).

Mocht je nieuwe website statische content zijn (of in dusdanige zin dat er weinig veranderd), dan kan je dit ook gelijk laten hosten door github.. scheelt ook gelijk bandbreedte.

[FireDrunk]

Redmine was vooral mijn idee, en niet vanwege Project Management, maar juist alleen voor bugtracking.
Wat ik een groot voordeel vind van Redmine is de GIT integratie. Maar als je github gebruikt heb je dat natuurlijk ook

Compleet project management gaat toch niet werken. Je kan volgens mij 100 sprints definieren (om maar even aan SCRUM te denken) maar daar gaan CiPHER en Jason zich toch niet aan houden

[ikkeenjij36]

Nou als non expert ben ik blij dat er nu een beetje duidelijkheid komt/is wat er gaat gebeuren.
Ik zelf persoonlijk blijf nu toch bij zfsguru en wacht af wat er gaat komen.
Ook al is geduld hebben geen makkelijk iets.
Vorige maand opnieuw alles en met een clean install gemaakt en alles geupdate naar het laatse en alles draait nu perfect.
Nu alleen nog maar wachten op wat komen gaat.

[Verwijderd]

Midas.e schreef op maandag 03 februari 2014 @ 00:32:
Waarom pak je eigelijk niet gewoon een VPS met freebsd erop? scheelt je zoeken naar een coloboer en hardware schrapen. Later kan je dat altijd nog doen zodra je meer resources nodig hebt.

Uit security overwegingen is zelf controle over de server hebben een grote plus natuurlijk. Security is voor de master servers heel belangrijk. Middels jails en firewalls kunnen we wel extra services draaien op hun eigen publieke IP. Maar in de toekomst willen we ook slave servers, die min of meer lokale caches zijn. Je kunt dan je eigen slave server draaien; de master servers blijven onder ZFSguru controle. Idee is dat er ook certificaten gebruikt gaan worden in de toekomst om slave servers te valideren. Dan zijn ook rogue slave servers ontmaskerd.

DXaroth schreef op maandag 03 februari 2014 @ 00:51:
Niet om het een of ander, maar je wilt veel te veel in 1 klap (ook al is het een klap van 6 maanden).

Gebeurt er eindelijk wat, is het wéér niet goed.

Maar serieus, er is al lang over gepraat. Nu maar gewoon maken die wiki en bugtracker. Dan gaat het maar ten koste van iets development tijd voor ZFSguru core. Als dat de community al eerder kan aanwakkeren, is dat weer in balans met elkaar.

FireDrunk schreef op maandag 03 februari 2014 @ 08:39:
Redmine was vooral mijn idee, en niet vanwege Project Management, maar juist alleen voor bugtracking.
Wat ik een groot voordeel vind van Redmine is de GIT integratie. Maar als je github gebruikt heb je dat natuurlijk ook

Het argument tegen Git is dat het meer Linux-geörienteerd is; FreeBSD zelf werkt met Subversion. Ook is svn in de ZFSguru build environment is geïntegreerd. Alles kan veranderd worden, maar een subversion backend ligt misschien meer voor de hand?

Maar de discussie over welke repo kunnen we misschien beter later voeren. Zaken als wiki, bugtracker en documentatie zijn denk ik belangrijker.

[CurlyMo]

Verwijderd schreef op dinsdag 04 februari 2014 @ 21:10:
Het argument tegen Git is dat het meer Linux-geörienteerd is; FreeBSD zelf werkt met Subversion. Ook is svn in de ZFSguru build environment is geïntegreerd. Alles kan veranderd worden, maar een subversion backend ligt misschien meer voor de hand?

Hoe kom je daarbij? Git is gewoon taal- en platform onafhankelijk. Kijk hier maar eens:
http://adambard.com/blog/...anguages-for-2013-so-far/

C is niet eens de meest gehoste code. Staat pas op de 6de plaats.

Vrijwel iedereen roept hier Git en jij wilt dan voor Subversion kiezen
Git is naar mijn idee superieur aan Subversion als het gaat om samenwerken in een community.

Maar de discussie over welke repo kunnen we misschien beter later voeren. Zaken als wiki, bugtracker en documentatie zijn denk ik belangrijker.

Zoals ook vrijwel iedereen al gezegd heeft is dat die repo discussie juist verbonden is met de wiki en bugtracker. Git kan alle drie perfect combineren in een begin stadium.

[FireDrunk]

Ik gebruik al maanden git onder FreeBSD, en dat werkt vlekkeloos...

[CurlyMo]

Ik ook. Zowel onder Linux, FreeBSD en Windows werk ik aan dezelfde repositories.

[DXaroth]

Verwijderd schreef op dinsdag 04 februari 2014 @ 21:10:
[...]

Gebeurt er eindelijk wat, is het wéér niet goed.

Maar serieus, er is al lang over gepraat. Nu maar gewoon maken die wiki en bugtracker. Dan gaat het maar ten koste van iets development tijd voor ZFSguru core. Als dat de community al eerder kan aanwakkeren, is dat weer in balans met elkaar.


[...]

Het argument tegen Git is dat het meer Linux-geörienteerd is; FreeBSD zelf werkt met Subversion. Ook is svn in de ZFSguru build environment is geïntegreerd. Alles kan veranderd worden, maar een subversion backend ligt misschien meer voor de hand?

Maar de discussie over welke repo kunnen we misschien beter later voeren. Zaken als wiki, bugtracker en documentatie zijn denk ik belangrijker.

Het argument dat het linux-oriented is, is complete onzin.. git is een van de meest-gebruikte VCS die er op dit moment is.. en het feit dat de BSD heren zo hard bij SVN blijven zegt meer over hun dan over git/svn...

Bedenk wel he, dat svn opzetten, en een eigen wiki, en een eigen bugtracker, enorm veel tijd kost.. iets wat je -en- gratis, -en- makkelijk kan doen door git te gebruiken.
En daarnaast, waarom wil je een half jaar bezig zijn met servers, die je zelf moet onderhouden, en updaten, en allerlei andere taken waar -jij- tijd in moet stoppen... dat is niet nuttig, dat is niet efficiënt, en zeker niet aan te raden

[edit] also, bedenk wel dat een repository hebben niet betekend dat je ook daadwerkelijk de code er in hoeft te douwen....

[ Voor 4% gewijzigd door DXaroth op 04-02-2014 22:12 ]

[syl765]

FreeNAS en DragonflyBsd gebruiken ook Git.
Ik zou echt geen reden kunnen bedenken om niet op de git trein te stappen.
En het grootste voordeel als je op de git trein stapt is natuurlijk het feit dat je de meeste deadlines uit het testament gaat halen.

[Verwijderd]

Ohjee, denk ik even dat subversion logischer is omdat FreeBSD dat ook gebruikt, krijg ik de wind van voren.

Ik kijk net even op FreshBSD en zie inderdaad dat FreeNAS ook git gebruikt; ik dacht dat alles op FreshBSD subversion gebruikte.

Als jullie git willen, prima. Maar besef dat Jason (en ik) er ook mee moeten gaan werken, het moet ook handig voor ons zijn. Bovendien heeft Jason een sterke wens om alles zelf te hosten, zelf controle houden over de infrastructuur. Dus als jullie praten over Github en in één keer alle problemen weg dan zijn jullie een deel van de discussie vergeten; daar zaten haken en ogen aan.

De weg die we nu bewandelen is juist gefocused op de nieuwe server met meerdere IPs en jails, waarin zaken als wiki en bugtracker en uiteindelijk ook repo in een eigen jail gaan draaien, met eigen SSL-certificaat en eigen domeinnaam zoals git.zfsguru.com. Voor alle diensten gebruik je dan dezelfde ZFSguru login, op zo'n manier dat een succesvolle aanval op de ene jail geen bruikbare logingegevens in handen krijgt van de overige services.

Zodra Mesa zover is, zullen de wiki's geïntegreerd worden. De oude wiki zal worden verwijderd, maar niet voordat de inhoud gekoppeld aan alle user accounts wordt overgebracht naar de community database waarbij publieke wiki ook beschikbaar is op de publieke ZFSguru site, maar wel via de web-interface te bewerken is. Daar zijn allerlei ideeën over. Nu er eerder dan gepland een 'tijdelijke' wiki komt, willen we dat wel goed afstemmen met wat komen gaat, dat lijkt me logisch.

Ik ga me eerst even inlezen over Git. Ik heb het alleen gebruikt voor checkouts, niet voor commits. Als Jason geen bezwaren heeft, vind ik het wel prima.

[CurlyMo]

Ik zal iig even mijn C minimal websocket capable webserver (+/- 500kb) even afmaken (gestript uit pilight). Zo kan je de C daemon draaien als webserver en dan gewoon een socket connectie leggen tussen de daemon en welke taal dan ook. De daemon is dan de brug tussen je website en je script taal.

---

Verwijderd schreef op dinsdag 04 februari 2014 @ 23:17:
Ohjee, denk ik even dat subversion logischer is omdat FreeBSD dat ook gebruikt, krijg ik de wind van voren.
[...]
Maar besef dat Jason (en ik) er ook mee moeten gaan werken, het moet ook handig voor ons zijn. Bovendien heeft Jason een sterke wens om alles zelf te hosten, zelf controle houden over de infrastructuur.
[...]
De weg die we nu bewandelen is juist gefocused op de nieuwe server met meerdere IPs en jails, waarin zaken als wiki en bugtracker en uiteindelijk ook repo in een eigen jail gaan draaien, met eigen SSL-certificaat en eigen domeinnaam zoals git.zfsguru.com.

Met alle respect. Ik krijg steeds vaker het idee dat jullie maar weinig weten van de materie waarover we hier discussiëren, laat staan er dan goede keuzes in kunnen maken. Of het nu kleine voorbeelden zijn zoals php code tags niet afsluiten als grote voorbeelden zoals volledige root www-data gebruiker of nog nooit met een VCS gewerkt te hebben. Volg gewoon de adviezen die hier unaniem gegeven worden i.p.v. gelijk naar je utopie te willen.

[ Voor 66% gewijzigd door CurlyMo op 04-02-2014 23:29 ]

[DXaroth]

Als je zelf de repo wilt hosten, is ook prima, gebruik dan gitlab.. dat heeft voor 80% de features van github, maar is dan voor prive hosting.. als je wilt zien hoe/wat het is, stuur dan een DM, ik heb het zelf draaien voor eigen gebruik (heeft ook wiki, en bugtracker, en repo)... ook een snelle toer door git kan je in DM terecht.

[ Voor 4% gewijzigd door DXaroth op 04-02-2014 23:38 ]

[Verwijderd]

Goed plan.

[onox]

CiPHER, voordat je denkt dat de wereld alleen maar een en al Git is; heb je ook al eens naar Mercurial gekeken? Python gebruikt het bijvoorbeeld. Op hginit.com vind je een tutorial (inclusief Subversion re-education) geschreven door Joel Spolsky.

[DXaroth]

onox schreef op woensdag 05 februari 2014 @ 10:06:
CiPHER, voordat je denkt dat de wereld alleen maar een en al Git is; heb je ook al eens naar Mercurial gekeken? Python gebruikt het bijvoorbeeld. Op hginit.com vind je een tutorial (inclusief Subversion re-education) geschreven door Joel Spolsky.

Zo denderend veel verschil is er niet tussen git en hg; en ik denk ook dat een discussie over 'welke DVCS beter is' niet erg constructief gaat zijn voor enige vorm van vooruitgang

[FireDrunk]

Couldn't agree more...

[Verwijderd]

Ik heb gespeeld met GitLab en ik moet zeggen dat ik er erg tevreden over ben. Het is simpel, niet teveel knopjes, maar de belangrijke functionaliteit zit er wel in. Het ziet er redelijk goed uit, niet té nerdy zoals andere pakketten.

En bedankt voor de tip onox. Echter, je kunt zien wat de reactie was toen ik een tijdje hierboven Subversion voorstelde als misschien een logischere keuze dan Git.... ik kreeg gelijk de wind van voren.

Dus laat het dan maar Git worden, anders wordt over de keuze voor Git/SVN/CVS/RCS nog maanden discussie gevoerd en daar heb ik niet zo'n zin in. Gitlab voldoet denk ik aan alle grote wensen:

• Het is git en niet svn/cvs
• Het is self-hosted, zoals Jason graag wilde
• Het biedt integratie voor Wiki en Bugtracker
• Werkt met login accounts die wellicht gekoppeld kunnen worden aan de Mesa database voor shared login password.
• Ziet er minimalistisch uit zonder teveel poespas maar heeft wel alle belangrijke functionaliteit.
• Blijft in ontwikkeling

Enig nadeel is dat er nog geen goede FreeBSD port van is. Maar ik kan mijn tanden er eens in bijten en een ZFSguru service ervan maken, hopelijk heb ik dan genoeg kennis om het uit te gaan rollen op de nieuwe server.

[CurlyMo]

Waarom tot die tijd niet gewoon github?

[DXaroth]

Verwijderd schreef op woensdag 05 februari 2014 @ 16:06:
Ik heb gespeeld met GitLab en ik moet zeggen dat ik er erg tevreden over ben. Het is simpel, niet teveel knopjes, maar de belangrijke functionaliteit zit er wel in. Het ziet er redelijk goed uit, niet té nerdy zoals andere pakketten.

En bedankt voor de tip onox. Echter, je kunt zien wat de reactie was toen ik een tijdje hierboven Subversion voorstelde als misschien een logischere keuze dan Git.... ik kreeg gelijk de wind van voren.

Dus laat het dan maar Git worden, anders wordt over de keuze voor Git/SVN/CVS/RCS nog maanden discussie gevoerd en daar heb ik niet zo'n zin in. Gitlab voldoet denk ik aan alle grote wensen:

• Het is git en niet svn/cvs
• Het is self-hosted, zoals Jason graag wilde
• Het biedt integratie voor Wiki en Bugtracker
• Werkt met login accounts die wellicht gekoppeld kunnen worden aan de Mesa database voor shared login password.
• Ziet er minimalistisch uit zonder teveel poespas maar heeft wel alle belangrijke functionaliteit.
• Blijft in ontwikkeling

Enig nadeel is dat er nog geen goede FreeBSD port van is. Maar ik kan mijn tanden er eens in bijten en een ZFSguru service ervan maken, hopelijk heb ik dan genoeg kennis om het uit te gaan rollen op de nieuwe server.

In theorie hoeft er weinig geport te worden naar FreeBSD, zolang ruby (en de modules) werken, en de services die het nodig heeft (goede git versie, redelijke up-to-date nginx, mysql/postgres), dan zal je er weinig problemen mee hebben... sinds 6.4 is er ook een 'update script' voor gitlab zelf (jammergenoeg nog niet voor gitlab-ci), die het meeste van de ruby taken voor zich neemt (code updaten, migraties draaien, repositories updaten, etc)..

Het is niet zozeer dat hg beter/slechter is dan git.. beide zijn beter dan svn (ooit geprobeerd zinnig te branchen in svn? of een corrupte repository te fixen? ik jammergenoeg wel ) en de soortgelijken.. maar de voorkeur tussen hg en git is puur persoonlijke voorkeur.

Mocht je nog hulp nodig hebben met gitlab aan de praat krijgen, je weet me te vinden

[EnerQi]

CurlyMo schreef op woensdag 05 februari 2014 @ 17:06:
Waarom tot die tijd niet gewoon github?

Pick your battles . We kunnen niet alles hebben hè

[Verwijderd]

Zijn allerlei redenen voor. Maar om eerlijk te zijn; ik heb nu mijn pijlen gericht op Gitlab en dat voldoet denk ik aan vrijwel alle wensen. Dus laten we niet overal discussie over voeren; voor mij is nu het punt om knopen door te hakken en gewoon voor een oplossing te gaan; en dat is Gitlab. Prachtig ding!

Alleen nu nog werkend krijgen. De port op reports is niet helemaal werkend; ik ben er nog mee bezig. Als ik het werkend heb, kan ik er lokaal wat mee spelen en dan zou het op termijn gehost kunnen worden. Mits Jason ermee instemt, maar dat verwacht ik wel. Self hosted en account security zijn gedekt. Al moet ik natuurlijk nog wel de one-way hash password verification schrijven voor Gitlab. Daarna kun je met je ZFSguru account naar Gitlab toe, zonder dat hiermee de logingegevens voor de overige ZFSguru service in gevaar komen. Dat kan met wat hashtechniekjes. Maart is denk ik wel optimistisch voordat het allemaal werkt; nieuwe server en alles gereed voor publieke entries. Maar dan heb je ook wat.

[DXaroth]

Verwijderd schreef op woensdag 05 februari 2014 @ 23:11:
Zijn allerlei redenen voor. Maar om eerlijk te zijn; ik heb nu mijn pijlen gericht op Gitlab en dat voldoet denk ik aan vrijwel alle wensen. Dus laten we niet overal discussie over voeren; voor mij is nu het punt om knopen door te hakken en gewoon voor een oplossing te gaan; en dat is Gitlab. Prachtig ding!

Alleen nu nog werkend krijgen. De port op reports is niet helemaal werkend; ik ben er nog mee bezig. Als ik het werkend heb, kan ik er lokaal wat mee spelen en dan zou het op termijn gehost kunnen worden. Mits Jason ermee instemt, maar dat verwacht ik wel. Self hosted en account security zijn gedekt. Al moet ik natuurlijk nog wel de one-way hash password verification schrijven voor Gitlab. Daarna kun je met je ZFSguru account naar Gitlab toe, zonder dat hiermee de logingegevens voor de overige ZFSguru service in gevaar komen. Dat kan met wat hashtechniekjes. Maart is denk ik wel optimistisch voordat het allemaal werkt; nieuwe server en alles gereed voor publieke entries. Maar dan heb je ook wat.

Ik neem aan dat de ZFSguru service niet op ldap werkt?

also, wat mist er aan qua port? gebruik je de guide van gitlab's public wiki? ( https://github.com/gitlab...icial-Installation-Guides ) .. die zou op de meeste systemen moeten werken

[Rikkiz0r]

Verwijderd schreef op woensdag 05 februari 2014 @ 23:11:
Zijn allerlei redenen voor. Maar om eerlijk te zijn; ik heb nu mijn pijlen gericht op Gitlab en dat voldoet denk ik aan vrijwel alle wensen. Dus laten we niet overal discussie over voeren; voor mij is nu het punt om knopen door te hakken en gewoon voor een oplossing te gaan; en dat is Gitlab. Prachtig ding!

Alleen nu nog werkend krijgen. De port op reports is niet helemaal werkend; ik ben er nog mee bezig. Als ik het werkend heb, kan ik er lokaal wat mee spelen en dan zou het op termijn gehost kunnen worden. Mits Jason ermee instemt, maar dat verwacht ik wel. Self hosted en account security zijn gedekt. Al moet ik natuurlijk nog wel de one-way hash password verification schrijven voor Gitlab. Daarna kun je met je ZFSguru account naar Gitlab toe, zonder dat hiermee de logingegevens voor de overige ZFSguru service in gevaar komen. Dat kan met wat hashtechniekjes. Maart is denk ik wel optimistisch voordat het allemaal werkt; nieuwe server en alles gereed voor publieke entries. Maar dan heb je ook wat.

Ik wil je eventueel wel helpen met een GitLab server, draai er hier ook één dus

[onox]

DXaroth schreef op woensdag 05 februari 2014 @ 10:24:
[...]

Zo denderend veel verschil is er niet tussen git en hg; en ik denk ook dat een discussie over 'welke DVCS beter is' niet erg constructief gaat zijn voor enige vorm van vooruitgang

Wat is nou je probleem gast? Ik krijg met je post de indruk dat je het mensen kwalijk neemt als ze anderen wijzen op het bestaan van alternatieven. Overigens is Gitlab een prima keuze, ziet er goed uit.

[DXaroth]

onox schreef op donderdag 06 februari 2014 @ 00:12:
[...]


Wat is nou je probleem gast? Ik krijg met je post de indruk dat je het mensen kwalijk neemt als ze anderen wijzen op het bestaan van alternatieven. Overigens is Gitlab een prima keuze, ziet er goed uit.

Mijn 'probleem' is dat ik, net als vele anderen, graag zie dat het project vooruit gaat. ik heb geen afkeer op andere ideeën, maar als na veel discussie de consensus van A naar Ab is over gegaan, dan heeft het mijn inziens geen enkel nut om ook nog eens een nieuwe discussie te starten om van Ab naar Ac te gaan (en blijkbaar was ik niet de enige met die het nut daar niet van in zag)... helemaal niet als het verschil tussen Ab en Ac niet veel meer is dan persoonlijke voorkeur.

[ Voor 3% gewijzigd door DXaroth op 06-02-2014 00:37 ]

[Verwijderd]

Heren, rustig aan. Persoonlijke vetes zit ik ook niet op te wachten. Alternatieven bespreken is prima, maar ik zit ook op het punt van beslissingen maken en doen ipv praten.

Voor elk van de opties valt wat te zeggen, maar als Gitlab kan wat we willen en bij alle partijen goed valt, wil ik dat gewoon gaan proberen. Dan hebben we straks een redelijk goede infrastructuur voor contributies en bugtracking en documentatie, wat ook goed aansluit op de ambities op langere termijn. Prima dus.

Ik ga morgenavond verder met het configgen van Gitlab; die Redmine port ben ik niet zo over te spreken. Misschien moet ik het eens from-scratch gaan doen. Wordt vervolgd.

[FireDrunk]

Redmine is heel wat anders dan Gitlab. Redmine is een project management tool gemaakt om feature requests in hapklare brokken te gieten (Sprints). Het werkt (met de goede plugins) volgens de SCRUM methode, waar je een backlog hebt met issues die nog opgelost moeten worden.

Heel anders dan Git(Lab) wat veel meer platgeslagen is.

Als je redmine goed zou gebruiken, zouden jullie veel meer structuur in je project krijgen, maar aangezien je al keihard riep dat je niet van deadlines hield, zal Redmine je niet bevallen. Qua programma is het so-so, (Ruby-on-Rails icm Passenger onder Apache) qua functionaliteit zal het je niet trekken gok ik zo.

GitLab is de betere keuze voor nu.

[ikkeenjij36]

*ik help je heel graag, maar dit topic is écht de plek hier niet voor*

[ Voor 84% gewijzigd door Verwijderd op 07-02-2014 18:56 ]

[ikkeenjij36]

ikkeenjij36 schreef op vrijdag 07 februari 2014 @ 18:43:
[mbr]*ik help je heel graag, maar dit topic is écht de plek hier niet voor*[/]

Beste cipher je hebt een dm en bedankt en sorry.

[Verwijderd]

Is prima hoor.

Ik wilde deze discussie alleen niet laten verwateren tot een algemeen ZFSguru topic; dus alles wat niet met deze discussie te maken heeft liever in ZFS topic of via DM.

[FireDrunk]

http://www.theopensourcew...ct_is_doomed_to_FAIL.html

Size
o The source code is more than 100 MB. [ +5 points of FAIL ]
o If the source code also exceeds 100 MB when it is compressed [ +5 points of FAIL ]
Source Control
o There is no publicly available source control (e.g. cvs, svn, bzr, git) [ +10 points of FAIL ]
o There is publicly available source control, but:
o There is no web viewer for it [ +5 points of FAIL ]
o There is no documentation on how to use it for new users [ +5 points of FAIL ]
o You've written your own source control for this code [ +30 points of FAIL ]
o You don't actually use the existing source control [ +50 points of FAIL ]
Building From Source
o There is no documentation on how to build from source [ +20 points of FAIL ]
o If documentation exists on how to build from source, but it doesn't work [ +10 points of FAIL ]
o Your source is configured with a handwritten shell script [ +10 points of FAIL ]
o Your source is configured editing flat text config files [ +20 points of FAIL]
o Your source is configured by editing code header files manually [ +30 points of FAIL ]
o Your source isn't configurable [ +50 points of FAIL ]
o Your source builds using something that isn't GNU Make [ +10 points of FAIL ]
o Your source only builds with third-party proprietary build tools [ +50 points of FAIL ]
o You've written your own build tool for this code [ +100 points of FAIL ]
Bundling
o Your source only comes with other code projects that it depends on [ +20 points of FAIL ]
o If your source code cannot be built without first building the bundled code bits [ +10 points of FAIL ]
o If you have modified those other bundled code bits [ +40 points of FAIL ]
Libraries
o Your code only builds static libraries [ +20 points of FAIL ]
o Your code can build shared libraries, but only unversioned ones [ +20 points of FAIL ]
o Your source does not try to use system libraries if present [ +20 points of FAIL ]
System Install
o Your code tries to install into /opt or /usr/local [ +10 points of FAIL ]
o Your code has no "make install" [ +20 points of FAIL ]
o Your code doesn't work outside of the source directory [ +30 points of FAIL ]
Code Oddities
o Your code uses Windows line breaks ("DOS format" files) [ +5 points of FAIL ]
o Your code depends on specific compiler feature functionality [ +20 points of FAIL ]
o Your code depends on specific compiler bugs [ +50 points of FAIL ]
o Your code depends on Microsoft Visual Anything [ +100 points of FAIL ]
Communication
o Your project does not announce releases on a mailing list [ +5 points of FAIL ]
o Your project does not have a mailing list [ +10 points of FAIL ]
o Your project does not have a bug tracker [ +20 points of FAIL ]
o Your project does not have a website [ +50 points of FAIL]
o Your project is sourceforge vaporware [ +100 points of FAIL ]
Releases
o Your project does not do sanely versioned releases (Major, Minor) [ +10 points of FAIL ]
o Your project does not do versioned releases [ +20 points of FAIL ]
o Your project does not do releases [ +50 points of FAIL ]
o Your project only does releases as attachments in web forum posts [ +100 points of FAIL ]
o Your releases are only in .zip format [ +5 points of FAIL ]
o Your releases are only in OSX .zip format [ +10 points of FAIL ]
o Your releases are only in .rar format [ +20 points of FAIL ]
o Your releases are only in .arj format [ +50 points of FAIL ]
o Your releases are only in an encapsulation format that you invented. [ +100 points of FAIL ]
o Your release does not unpack into a versioned top-level directory (e.g. glibc-2.4.2/ ) [ +10 points of FAIL ]
o Your release does not unpack into a top-level directory (e.g. glibc/ ) [ +25 points of FAIL ]
o Your release unpacks into an absurd number of directories (e.g. home/johndoe/glibc-svn/tarball/glibc/src/) [ +50 points of FAIL ]
History
o Your code is a fork of another project [ +10 points of FAIL ]
o Your primary developers were not involved with the parent project [ +50 points of FAIL ]
o Until open sourcing it, your code was proprietary for:
o 1-2 years [ +10 points of FAIL ]
o 3-5 years [ +20 points of FAIL ]
o 6-10 years [ +30 points of FAIL ]
o 10+ years [ +50 points of FAIL ]
Licensing
o Your code does not have per-file licensing [ +10 points of FAIL ]
o Your code contains inherent license incompatibilities [ +20 points of FAIL ]
o Your code does not have any notice of licensing intent [ +30 points of FAIL ]
o Your code doesn't include a copy of the license text [ +50 points of FAIL ]
o Your code doesn't have a license [ +100 points of FAIL ]
Documentation
o Your code doesn't have a changelog [+10 points of FAIL]
o Your code doesn't have any documentation [ +20 points of FAIL ]
o Your website doesn't have any documentation [ +30 points of FAIL ]
FAIL METER
o 0 points of FAIL: Perfect! All signs point to success!
o 5-25 points of FAIL: You're probably doing okay, but you could be better.
o 30-60 points of FAIL: Babies cry when your code is downloaded
o 65-90 points of FAIL: Kittens die when your code is downloaded
o 95-130 points of FAIL: HONK HONK. THE FAILBOAT HAS ARRIVED!
o 135+ points of FAIL: So much fail, your code should have its own reality TV show.

Na wat uitzoeken, kom ik op:

[tromgeroffel]
560 punten
[/tromgeroffel]

[Verwijderd]

Gelijk pil van Driom dan maar.

Dat soort lijstjes zijn leuk, maar heel negatief. Het suggereert ook dat er maar één weg naar Rome zou zijn, en daar geloof ik niet in. Bovendien hebben we die discussie nu al gehad, en ben ik bezig met productieve dingen ipv maandenlang bakkeleien.

o You've written your own build tool for this code [ +100 points of FAIL ]
o Your source builds using something that isn't GNU Make [ +10 points of FAIL ]

Nogal door een gekleurde bril bekeken. Dezelfde gekleurde bril waardoor ik GitLab nog niet werkend heb: de dependencies zijn 'linuxified' en werken niet buiten Linux. Specifiek gaat het daarbij om de 'libv8' dependency; een soort server-side Javascript; wie bedenkt het. Als je daar nou wat strafpunten voor zou geven.

[FireDrunk]

Uiteraard zou je al die GNU meuk kunnen vertalen naar FreeBSD's varianten.
Dan kom je misschien een paar punten lager uit.

Maar dat van die Build tool is wel waar. Wij kunnen zelf toch geen ZFSguru images bakken?

[Verwijderd]

Nee, en dat zou ook niet mogen volgens die strafpuntenlijst. Dus ga voor de 'zogenaamd' goede manier en doe alles 'from-scratch' met vanilla FreeBSD. Veel plezier!

Ik ben in elk geval heel blij met de build infrastructuur. Maar als je zelf vindt dat dat de verkeerde manier is, dan bewandel je gewoon de vanilla route. Bedenk wel dat je een heel aantal uurtjes opzij kan zetten. Ook de voordelen van een 'appliance' waarbij je exact dezelfde software draait als anderen en dus bekende issues gerapporteerd kunnen worden, raak je dan kwijt.

[FireDrunk]

Dat zeg ik toch niet? Het gaat er om of het project echt "OPEN" source is... Jullie resultaten zijn niet reproduceerbaar door de eindgebruiker, dat is dus niet open source.

Mensen gebruiken ook .deb files. Die zijn ook gecompileerd. Niets mis mee... Het gaat er om of de resultaten reproduceerbaar zijn en je dus kan verifieren hoe packages tot stand komen.

[Verwijderd]

Zo valt er altijd wel wat te klagen, ook al hebben 'we' aan veel eisen toegegeven. Het zal nooit genoeg zijn voor sommigen. Als we alles openbaar maken dan is de licentie niet goed, en als we alles public domain maken dan is de code niet goed. Ik kan echter weinig met continu negatieve reacties, het is in elk geval weinig bevorderlijk voor het plezier wat ik in het project heb. Soms denk ik ook voor wie ik het eigenlijk doe. Bijna alles wat wij doen is verkeerd volgens jou en anderen. Heeft het dan wel zin om überhaupt door te gaan? Dat soort vragen stel ik mijzelf.

Maar dan moet ik denken aan alle mensen die wél zo blij zijn met ZFSguru. En niet zeuren om endtags of www-user of licentie of serverhosting of gebruikte conventies, maar juist een leuk eigenwijs en uniek product willen hebben wat zij laagdrempelig kunnen gebruiken. Een project met unieke features, unieke werkwijzen, eigen manier van doen. Maar dat alles 'mag' niet van sommigen; althans die indruk krijg ik soms. Maar waarom? Waarom zou je een sympathiek en idealistisch project als ZFSguru iets misgunnen? Ik snap dat niet zo.