Een eerste (poging tot) deelname door Bert Roex

Source: Hacktoberfest

Hacktoberfest is een jaarlijks evenement om bijdragen tot open source software toegankelijk te maken en aan te moedigen. Een initiatief waar ik grote voorstander van ben gezien ik zelf ook altijd op zoek ga naar open source libraries om mijn dagdagelijkse taken mee uit te voeren.

Het evenement wordt ondersteund door DigitalOcean, een Amerikaanse leverancier van cloudinfrastructuur die me vast ooit zo ver gekregen heeft mijn e-mailadres met hen te delen in ruil voor enkele dollars aan gratis hosting. Daarbovenop is het rond deze tijd van het jaar moeilijk de marketing campagne omtrent Hacktoberfest niet op je pad tegen te komen (reddit, Github).

Koudwatervrees

Het was ergens midden september wanneer ik een teaser mail van het evenement in mijn mailbox zag verschijnen. Naar goede gewoonte post ik het direct in de slack van ons team, waar net zoals ik de meesten wel interesse tonen en toch een afwachtende houding aannemen. Is dat wel iets waar ik me aan wil wagen? Koudwatervrees hield mij eerder ook tegen, bovendien herinner ik me dat ik voorheen reeds op zoek gegaan was naar een openstaand issue waar ik van dienst kon zijn en er achter kwam dat die zoektocht niet evident is.

Doordat er goodies te 'verdienen' zijn, wordt de community bovendien overspoeld met personen die nutteloze veranderingen proberen op te dringen om aan het nodige aantal contributies te komen, waardoor legitieme contributies alsmaar meer voorwaarden met zich mee brengen.

De zoektocht

Dit jaar heb ik net dat beetje meer zelfdiscipline opgelegd en de documentatie voldoende doornomen om concreter op zoek te gaan naar openstaande issues. Het helpt ook dat ik wel zicht heb op wat de meeste projecten inhoudelijk te bieden hebben omdat ik in de loop der jaren met een groot aantal reeds in contact gekomen ben. Ik maakte eerst een selectie van projecten waaraan ik graag een bijdrage zou leveren. Daarna ben ik openstaande issues gaan overlopen die me haalbaar leken. Hier bleek opnieuw een horde te nemen, gezien naar mijn gevoel een groot aantal openstaande issues toch extra context vereist in de werking van bepaalde onderdelen van het project. Uiteindelijk bleek er niet veel over te blijven van mijn selectieprocedure en besloot ik te starten aan een openstaande issue van jackson-databind namelijk "@JsonAnyGetter should be allowed on a field", ik las dat het voor de setter alvast mogelijk was en dacht op die manier te kunnen reverse-engineeren hoe ik dit ook op de getter kon toepassen.

Een eerste poging

Met goede moed clone ik de jackson-databind repository en nadat Maven schijnbaar het hele internet probeert te downloaden laat ik mijn IDE het zoekwerk verrichten naar JsonAnySetter referenties. Het exact aantal resultaten heb ik intussen verdrongen, dit issue gaat het niet worden voor me. Op naar de volgende dan maar...

Een tweede poging

Integratie met cloud diensten komt wel vaker op ons pad en dus ben ik reeds vertrouwd met de AWS Java SDK, hier vond ik een openstaand issue dat me opnieuw haalbaar leek.

Wanneer een request via een builder patroon wordt aangemaakt gingen de request parameters van een aangeleverde URI verloren, er werd geopperd dat deze behouden zouden moeten worden.

Als snel werd me duidelijk waar ik kon inhaken om deze logica toe te voegen en al snel had ik een eerste versie "klaar". Ik had een eigen unit test bij geschreven en dacht al sterk gewapend te zijn tegen enige regressie op de manier hoe ik het aangepakt had.

Tijd om een pull request te openen, dus neem ik de voorwaarden grondig door.

Checklist

• I have read the CONTRIBUTING document
  
  
• Local run of mvn install succeeds
• My code follows the code style of this project
  
  
• Toch regressie op bestaande test
• Checkstyle issue op volgorde van imports
  
  
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed
  

Peer review

Fijn, uiteindelijk runt lokaal een mvn install zonder issues, waarvan vooral de strikte checkstyle (die ik door IntelliJ niet direct opgepikt kreeg) me stilaan begonnen ontmoedigen. Ik open een pull request en vergezelde deze van een comment om me niet te hard aan te pakken gezien het mijn eerste bijdrage is. Daar stonden mijn veranderingen dan te blinken, wachtend op een review. De initiële review gebeurde verbazend snel, binnen het uur verscheen er reeds een antwoord.

Ga terug naar start

De review is to-the-point. De change is in zijn huidige vorm mogelijk niet voor iedereen backwards compatible, gezien voorheen eventueel reeds parameters doorgegeven werden die er vanaf gestript werden waardoor gebruikers van de SDK er op kunnen steunen dat deze verwaarloosbaar zijn. Het voorstel is om er een extra boolean vlag voor te voorzien op de builder.

Een change waarvan ik zelf het nut in zie en graag nog wat extra inspanning lever.

Niet alleen op de wereld

Wanneer ik de verandering heb doorgevoerd herinner ik me aan het feit dat men de historiek van publieke repositories graag overzichtelijk houdt.

Dit keer faalt de Continuous Integration (TravisCi) helaas, schijnbaar doordat er changes zijn doorgevoerd op de hoofdtak (upstream/main branch) van het project.

Ik slaag er niet in deze changes op mijn branch te krijgen en door wat GIT history changing events te triggeren en te force pushen kom ik er achter dat mijn pull request intussen automatisch gesloten werd. Deze manier van werken wijkt sterk af van mijn vaste workflow.

Gelukkig ben ik niet de eerste die dit tegenkomt en hebben we hiervoor een enkele tips voorhanden:
Bijdragen aan Open Source

Het over een ander boeg gooien

Ik beslis de squashed commit die ik lokaal heb naar een patch file te patchen waarna ik tracht om mijn branch terug up-to-date te brengen met de upstream main.

Opnieuw een confrontatie dat de hele ceremonie rond veranderingen doorvoeren in deze context veel meer consequenties heeft dan dat je in een eigen project typisch tegenkomt.

Ik heb intussen beslist mijn test cases te verhuizen naar een reeds bestaande test file, SonarQube had mijn test file wel opgepikt maar rapporteerde bij een vorige run dat er geen coverage was voor de lijnen die ik had toegevoegd, terwijl ik deze met zekerheid wel coverede.

Mijn lokale build slaagt terug dus ik waag me aan het openen van een nieuwe pull request.

Helaas, het lijkt een soort dans waarin er meer stappen achteruit dan vooruit plaatsvinden.

TravisCI runt zowel één keer met Java 8 als met Java 11

[ERROR]   Http2MetricsTest.maxClientStreamsHigherThanServerMaxStreamsReportServerMaxStreams:121 » IndexOutOfBounds
[ERROR] Tests run: 239, Failures: 0, Errors: 1, Skipped: 0

Deze zelfde test slaagt lokaal wel, ook wanneer ik expliciet met Java 8 run.

Met Java 11 faalde hij vanwege:

The job exceeded the maximum time limit for jobs, and has been terminated.

Hier lijk ik zelf weinig controle over te hebben.

Bij mijn vorige pull request kon ik doorklikken op de sonar run, ditmaal geraak ik niet verder dan een AWS console login scherm waarvan ik niet zou weten met welke credentials ik toegang kan krijgen.

Naar hoe / of deze opnieuw te triggeren zijn heb ik het raden.

Waar ik initieel nog razendsnel feedback kreeg op mijn pull request dien ik bij mijn tweede poging meer geduld uit te oefenen.

De review is niet mals maar wel constructief. Ik pik de changes op en wacht opnieuw af.

We hebben nog een aantal iteraties nodig maar kunnen landen op een oplossing die alle betrokkenen elegant vinden.

Een gevoel van overwinning overvalt me wanneer ik de notificatie zie binnen komen.

Een 3e issue

In het laatste jaar werd ik onvoorbereid terug in een Spring context geworpen en had ik het geluk te kunnen starten van een JHipster code generator om snel terug up to speed te geraken met huidige best practices. Het sprak dan ook voor zich dat ik graag deze repositories verbeter waar ik kan. Ik stootte op volgend issue https://github.com/jhipster/jhipster-online/issues/213.

Laat test coverage nu net iets zijn waar we bij XTi zeer kritisch mee omgaan. Niet klakkeloos line coverage omhoog brengen, maar kritisch zoeken naar de business kritieke paden van de code en deze met de nodige permutaties aftoetsen.

Ik vraag Sudharaka als auteur van het issue of dit ticket in aanmerking kan komen voor Hacktoberfest en hij is vrijwel onmiddellijk welwillend om het label aan het ticket toe te voegen.

Ik schrik er lichtjes van dat de code coverage voor een project waar ik vrij blindelings op steunde een zeer matige coverage van ongeveer 50% heeft.

Ik merk een minder elitair gedrag op en ervaar een eerder pragmatische aanpak op dit project.

Er wordt opgelijst welke classes het meeste lijden onder het gebrek aan testen en de gehele lijst wordt erkend als uitdagend om in één enkele keer toe te voegen.

Ik had een aantal classes reeds zelf opgepikt en groepeer deze in een eerste pull-request en deel de volgende op per class die ik test. Ook de goedkeuring loopt hier een pak vlotter.

De maand ging sneller voorbij dan verwacht en een zoektocht naar een nieuw issue bleef uit. Wel heb ik verschillende testen in verschillende pull-requests geopend. Stiekem hoop ik zo toch de treshold te behalen om een T-shirt in de wacht te slepen, het hielp trouwens om de review gespreid en gerichter te doen verlopen.

Conclusie

Het vergt heel wat toewijding om een bijdrage te leveren aan open source software. Toch is het erg dankbaar op meerdere vlakken gezien vele handen licht werk maken, je er zelf veel van opsteekt dat je anders niet snel zal tegenkomen en je open source software beter zal appreciëren. We hebben geluk dat we in een sector actief zijn waarin zoveel mensen vanuit hun passie voor probleem oplossend denken zich onzelfzuchtig willen blijven inzetten voor betere oplossingen!