Twee vragen:
- Waarom zou het niet reproduceerbaar zijn?
- Waarom zou een nieuwe installer van mij beter zijn dan de installer van Adrie die gewoon gedownload kan worden?
(Ik heb niet één regel code aangepast, dus mijn versie is exact gelijk aan de laatste versie van Adrie)
Bij software development heb je al snel het "works on my machine syndrome". Bij de ene developer werkt het, compileert het, etc. Vervolgens ga je dat testen op een andere machine en dan blijkt er toch een verschil te zijn waardoor het niet meer werkt. Vaak zit 'm dit in de configuratie die op de ene PC toch anders is. De oplossing zit 'm dan in het configuratiebestand van de IDE of de compiler, die bij de broncode moet worden gestopt.
Jouw installer zal niet per se beter of anders zijn, daar gaat het hier niet om. Het gaat erom dat we bij dit software development project in staat zijn om vanuit versiebeheer een installer te kunnen produceren, wederom op een generieke en reproduceerbare wijze. Je wilt 100% zeker weten dat een build van versie X die op datum P wordt gemaakt exact hetzelfde resultaat oplevert als het bouwen van diezelfde versie X op datum Q.
Je zegt geen code te hebben aangepast, maar ik weet niet welke branch van de code je hebt gebruikt c.q. welke versie. Daarnaast kan ik niet zien welke wijzigingen je al dan niet hebt moeten doen aan de Lazarus configuratie. Die configuratie hebben we ook onder versiebeheer gebracht omdat bleek dat dit veel problemen gaf.
Het is onwijs goed nieuws dat er mensen zijn die het zonder problemen lukt om voor Windows te bouwen. Dat soort hulp kunnen we enorm goed gebruiken en daar zijn we ook heel blij mee. Maar ik hoop wel dat mensen begrijpen dat we niet of nauwelijks geholpen zijn bij "ja hij doet het bij mij hoor, hier is de .exe file!". Als je met elkaar samen software ontwikkelt moet je iets gebruiken van afspraken, versiebeheer enzovoort. Dan moet je nadenken over reproduceerbaarheid, testen, hoe je releases maakt enzovoort. Dat betekent dus dat een bijdrage fantastisch is maar wel via Github moet worden ingediend. Dan kunnen anderen meekijken en dan kunnen we samen iets moois maken. Daarom gebruiken we ook Slack, om snel en soepel te kunnen communiceren met elkaar, code te kunnen delen, enz enz. Daar is een forum als dit gewoon veel minder geschikt voor.
Klinkt misschien wat star allemaal, maar zo is het zeker niet bedoeld. Ik kan met 20 jaar ervaring in de IT en met software development, beheer en processen wel zeggen dat een set afspraken en werkwijzen wel echt noodzakelijk zijn om de kwaliteit te kunnen borgen.
Kortom: we zijn super blij als je wilt helpen, maar help ons dan ook door dit via Github te doen en contact te zoeken via Slack. Als je serieus wilt mee ontwikkelen nodigen we je daar dan uit voor het development kanaal en kunnen we elkaar helpen.
Tot slot: ik waardeer echt elke bijdrage hier maar hoop wel dat we met elkaar een wat meer positieve sfeer kunnen behouden. Iedereen die mee doet met de ontwikkeling van BrouwHulp / BrewBuddy doet dit vrijwillig en steekt hier eigen tijd in. Dat doen die mensen met liefde voor het pakket, voor bier brouwen en voor de community. Daarbij zullen we niet iedereen tevreden stellen, zal er soms kritiek zijn enzovoort. Maar ik roep iedereen op om ook oog te hebben voor die inzet van mensen en het feit dat we gewoon onze stinkende best doen. Om dit positieve en inclusieve sfeer ook binnen het software development te behouden hebben we daarom ook een "code of conduct" overgenomen die vrij standaard is bij open source software projecten. Deze staat ook op Github bij de code.
