Från och med i söndags (26/5-2019) så har buggrapporteringen migrerats från Redmine till GitHub. Vad får detta för konsekvenser för dig när du rapporterar buggar och problem? Det skall vi titta närmare på i detta inlägg.
Jag kommer inte att göra en uttömmande jämförelse med Redmine utan fokusera på tillvägagångssätt och metoder för GitHub. Det tjänar inget till att jämföra för- och nackdelar med Redmine, då det är GitHub som gäller. Det kommer inte att bli någon återgång, så det tjänar inget till att probleminventera jämfört med det som varit. Och skall jag vara ärlig så tycker jag inte att Redmine var speciellt användarvänligt…
Nu finns ”issues” på samma plats som källkoden till QGIS. Bara det känns logiskt. Nu kan koden tydligare kopplas till felrapporter och problemlösningar, men även framtidsplaner och så kallade ”milestones” är samlat här. Väldigt mycket som har med utvecklingen av programmet går med andra ord att nå via en url och med ett användarkonto.
Ja, du behöver ett användarkonto på GitHub för att anmäla fel och brister. Detta är enkelt att skaffa om du inte redan har ett, och det ger dig dessutom en egen GitHub sida där du kan samla och publicera din egen kod som du vill kunna dela med andra. Det är inte bara ”kod” som kan lagras här, utan all typ av digital information. Mer om möjligheterna med GitHub hittar du på startsidan https://github.com/.
Till att börja med så bör man söka efter det problem man upplever i QGIS, så att det inte redan är ett känt och anmält fel. Försök göra lite olika sökningar med olika formuleringar, så att det är så säkert som möjligt att det inte blir dubbla felrapporter.
När man skapa en ny ”issue” så får man välja om det är en bugg som skall rapporteras, eller om det är en funktion man vill få tillförd i QGIS. Så kallade ”feature requests” bör man vara försiktig med, speciellt om man verkligen vill lägga till den efterfrågade funktionen. Det är betydligt säkrare att kontakta någon av utvecklarna direkt och diskutera hur en implementering kan göras på bästa sätt och vad det kan kosta. Du bör med andra ord räkna med att någon behöver betala för att en ny funktion skall läggas till i programmet.
Det finns inget formulär på samma sätt som i Redmine, utan här redigerar man en text med förifyllda kommentarer och exempel. Allt som kan betecknas som kommentarer finns innanför <!– –> taggar i texten. Övrig text är exempel på hur du kan skriva.
Rubriker omges av stjärnor (**Rubrik**) och dessa bör du inte ändra på. Växla mellan ”Write” och ”Preview” för att kontrollera resultatet.
Det går att lägga till länkar till externa resurser, men även lägga till exempelvis skärmdumpar, projektfiler eller till och med data för att tydligare belysa problemet.
Ju mer tid du lägger på att tydliggöra problemet och göra det möjligt för andra att återskapa det, desto bättre och enklare är det för utvecklarna att bedöma allvarligheten och hur problemet skall angripas. Varje bugg märks sedan med olika taggar för att enklare hålla koll på dessa i den samlade listan, samt göra det möjligt att filtrera exempelvis ”High Priority” problem.
Slutligen
Rapporteringen är väldigt ”öppen” i och med att det är en text som skall redigeras och inte formulärfält som fylls i. Det är därför viktigt att du som rapporterar följer de anvisningar som ges i texten. Du kan även titta på tidigare rapporter för att snabbt bilda dig en uppfattning om hur formateringen är tänkt att fungera.
Att samla allt som har med utvecklingen att göra på ett ställe är jättebra, även om det råkar vara Microsoft som numera äger GitHub. Men det finns inte så många alternativ som är bättre just nu och QGIS är ett enormt stort projekt. Vi får väl se om villkoren för GitHub ändras så att OpenSource projekt av den här storleken påverkas negativt framöver, men det tror jag faktiskt inte. Det görs även vissa förberedelser om det skulle visa sig nödvändigt, att flytta all kod till GitLab, men det är ett ganska stort projekt.
Om du inte redan har ett GitHub konto, så kan detta vara ett väldigt bra tillfälle att skaffa ett. Du kommer att behöva det för att rapportera buggar och göra feature requests framöver, och det är ett jättebra sätt att dela och sprida alla former av kod, inklusive QGIS stilfiler, data och projekt.
När jag skriver detta så är hänvisningarna till GitHub inte uppdaterade på QGIS.org eller via programmet, men det är säkert bara en tidsfråga.