Fifty Releases of GPXSee

8.10.2017 00:33 | Přečteno: 1003× | LINUX

Člověk se ani nenaděje a z neškodné kratochvíle se stane projekt!

Jistě nadpis je tradičně trochu bulvární, těch 50 vydání se nestalo jen tak, ale určit kdy přesně se z kusu kódu projekt stane, není úplně lehké ani jednoznačné. Je to když naimplementujete první funkci, kterou vy nepotřebujete a chce jí někdo jiný? Je to když místo prostého sdílení kódu na Githubu začnete vydávat binární buildy? Nebo až když kromě programu samotného začnete řešit i jeho prezentaci, byť jen formou trochu slušnějšího webu?

Ať tak či onak, GPXSee už projektem zdá se je. Změny, které dělám čistě pro sebe už rozhodně netvoří drtivou většinu commitů a čas strávený na "neprogramovacích" úkolech (vydávání, web) už taky není nezanedbatelný. Na druhou stranu si nedělám iluze, že GPXSee někdy osloví masy a stane se nějakým hitem. Ač první commit je z roku 2015, v zásadě jde o software "z minulého tisíciletí". Bežný Franta Uživatel má dneska Stravu, nebo se na ní chystá přejít z Garmin connect nebo Endomonda. A ač i v roce 2017 je Trekbuddy na Nokii 2710 stále nepřekonané řešení, vývoj nezastavíš a budoucnost je v "pádlech" s výdrží na baterii v řádu minut, spíš než v řádu hodin...

Přesto, zdá se (podle počtu instalací i nenulové interakci veřejnosti na githubu), že nějaká "cílovka" tu je a pokuď bude program fungovat, své uživatele si najde. Kámen úrazu je ale v tom "bude fungovat". Zkušenosti ukazují, že u SW, který má široké množství ekvivivalentních alternativ, je počet uživatelů potřebný na nahlášení jednoho bugu někde mezi 50000-100000. (Pro software, který je jedinečný/nenahraditelný to neplatí - pokuď tedy například tvoříte firmware pro WiFi řízené parníčký do vany, budou vám bugy reportovat prakticky všichni (čtyři) uživatelé). Nemáte-li je, musíte QA strávit hromadu času už jenom proto, aby první spuštění vašeho veledíla nebylo pro uživatele také spuštěním posledním. Například GPXSee vzniklo mimo jiné i pro to, že pokus o otevření GPX logu v QLandkarte GT skončil takovou serií chyb a nefunkčností, že k dalšímu pokusu už vůbec nedošlo. Pro některé ale úplně stejně může končit i seznámení s GPXSee, například do verze 4.14 pokus o otevření TCX souboru s tepem končil stejně neslavně...

Jak se ale k těm desítkám tisíc uživatelů dostat? V případě linuxu prakticky pouze zařazením do "hlavních" distribucí. Od Leap 42.3 je GPXSee součástí OpenSUSE, ale tím to taky končí. Proběhl sice pokus o zařazení do Debianu, ale hráz byrokracie a nutnost nespočtu Debian specifických postupů se pro mě ukázala nepřekonatelná. Už jenom zjistit jak/co/kam správně zaslat žádost o zařazení je na několik večerů. Představa, že bude stačit dodat soubory, ze kterých se DEB balíčky vyrábí na OBS se ukázala býti lehce naivní. Pro Fedoru zdá se platí dtto a po zbytku už jsem radši ani nepátral... Pojďme tedy nyní ke skutečnému jádru tohoto trachtátu:

Najde se zde na ABCLinuxu někdo dostatečně kvalifikovaný, ochotný, s konexema, ... aby "protlačil" jeden bezvýznamný projekt do významných repozitářů? A nehlaste se všichni, jeden člověk bohatě stačí

       

Komentáře

[Michal Kubeček]

Říkal jsem si, že bych mohl pomoci s balíčkem pro openSUSE, ale tam už to zrovna máte, tak snad najdete někoho i pro ostatní.

[Martin Tůma]

Ano OpenSUSE už "bohužel" je pořešený. Kéž by to stejně dobře a jednoduše jako na OBS fungovalo například u Debianu... Trochu jsem ale doufal, že se třeba "chytne" někdo z RedHatu. Minimálně v diskuzích tu jsou Brňáci poslední dobou celkem aktivní

[Martin Tůma]

Napadla mě jedna věc, kde by SUSE mohlo případně pomoct a to je QA na big endian architektuře, pokuď tam nějaký takový železo máte. Předpokládám totiž, že normálně balíčky pro OpenSUSE nikdo na PowerPC explicitně netestuje. Můj pokus rozjet PowerPC OpenSUSE v QEMU skončil s koncem mé trpělivosti asi po 5h instalace, takže formáty, kde na endianitě záleží (např Garmin FIT, nebo OZF) jsou pro big endian napsaný "na slepo".

[Michal Kubeček]

Železo by nebyl problém (i když nejspíš ne přímo v Praze), ale u aktuálních openSUSE, tj. od 42.2 dál, už PowerPC znamená ppc64le, takže big endian už je vlastně jen s390x (S/390-64). V ports asi budou i 32-bitové buildy, ale přiznám se bez mučení, že jsem to nikdy instalovat nezkoušel, takže by to asi nešlo úplně hladce.

[Martin Tůma]

No vzhledem k tomu, že to znamená, že šance, že to vůbec někdo bude na BE zkoušet spustit je prakticky nulová tak bych to už asi dál nijak nehrotil

[RM]

Kdysi jsem něco takového hledal. Nakonec jsem ten graf nadmořské výšky a rychlosti udělal v pythonu; mapku s trasou jsem tuším měl z tangogps. Při tom jsem narazil na to, že mi GPS logger nachytá dost ujetých hodnot, pokud byl slabý signál, třeba v lese -- ty bylo třeba odstranit filtrem. Trochu mne překvapilo, že na tohle nikdo nepamatuje, přitom by stačilo v menu zadat max odchylku v nadmořské výšce a rychlosti, která má být ještě platná. Zdá se, že ani vy tam něco takového nemáte.

[Martin Tůma]

Problém "fyzikálních omezení" je, že není prakticky možné zvolit nějaké rozumné výchozí hodnoty tak, aby to fungovalo pro všechny oblasti používání. Rozdíl mezi pěší turistikou a leteckými daty (zejména IGC) je prostě příliš veliký.

GPXSee z toho důvodu implementuje "pouze" statistickou eliminaci odlehlých hodnot, nicméně ta má své limity a například u shluků chybových hodnot selhává.

[RM]

No alespoň tak, v tom případě by to mohlo být pro mne použitelné. Nicméně stále nechápu, jaký je problém s tím, mít někde možnost zadat, že data odpovídají chůzi a na základě toho pak brát, že odchylka dvou sousedních hodnot nemůže být větší než třeba 1m u výšky na 3m délky. Odstranit shluky takových chybných hodnot by mělo jít.

[Michal Kubeček]

Případně by ten threshold nemusel být zadáván jako absolutní, ale jako násobek průměrné rychlosti.

[Martin Tůma]

Problém je, že jsou reálné případy, kdy toto nefunguje. Například záznam z MTB. Průměr někde okolo 15km/h a pak 30s rychlost 60km/h. A teď - je to sjezd, nebo ztráta signálu? Jistě, dalo by se tady "opřít" o data elevace, řešit ostré úhly změny azimutu atd., nicméně už to není tak triviální, jak se na první pohled zdá.

[RM]

Stačí to "opřít" jen o tu elevaci. Ta totiž, jak se zdá, ulétne vždy, pokud je špatný signál.

[Martin Tůma]

Ta totiž, jak se zdá, ulétne vždy, pokud je špatný signál.

Vždy s vaší GPS, moje GPS zase naopak elevaci v případě špatného signálu dramaticky nemění. Je to závislé na GPS a/nebo SW co tvoří log stejně jako na aktivitě. Právě proto je tak těžké vymyslet/odladit něco, co funguje obecně.

[RM]

Tak ono by to u vaší GPS jen ty body neodstranilo, nic víc by se nestalo.

[Dan Horák]

Měl bych jednu připomínku, pokud jsem dobře hledal, tak v žádném autorem vytvořeném souboru není informace o licenci. Ideální je licenční hlavička v každém zdrojáku, ale postačí i explicitní zmínka v README. To jsou ty radosti s open-source Disclaimer: IANAL

[helb]

Je tam licence.txt s GPL3.

[Martin Tůma]

Jak už bylo zmíněno, součásti repa je soubor s licencí a v GUI je licence v about dialogu. Licence se dále vyskytuje ve Windows installeru a RPM balíčkách (Do deb se zase musí dodat přes nějaký speciální soubor...). Takže celkově mi to přijde, že kdo chce licenci znát, získá jí celkem snadno.

Tapetovat ale každej soubor licencí mi přijde zbytečný. Vím, že spousta SW to tak má, ale mě to moc nedává smysl - kdo chce, tu licenci stejně smaže a kdo jí potřebuje třeba pro jeden soubor, tak jí tam může doplnit. V GPXsee jsou třeba asi 3 takový soubory, který jsou "based on" a je to tam uvedeno.

[TurboLama]

Fedora:

• Copr repo: https://copr.fedorainfracloud.org/coprs/nforro/GPXSee/
• Review request: https://bugzilla.redhat.com/show_bug.cgi?id=1500524

[Martin Tůma]

Díky

[Martin Tůma]

Je nějaký "oficiální kanál" jak upozorňovat na nové verze? Nebo si to copr hlídá sám např podle tagů v gitu?

[marbu]

Pro balíčky, které jsou přímo součástí distribuce (a tvůj GPXSee projekt je na cestě se jím stát), provozuje Fedora službu release-monitoring.org, která upozorní správce balíčku, že vyšla nová verze. Dá se i nastavit, aby se to pokusilo udělat automaticky scratch build v koji a pod. Ale aby se balíček dostal do distribučního repa je nakonec vždy třeba práce správce balícku.

A GPXSee projekt už tam nastavený je, takže asi ok. Akorát se dívám, že poslední detekovaná verze je 4.15 a ty jsi včera vydal 4.16 a já nevím, jak často se ta kontrola dělá.

[Martin Tůma]

Zdá se, že ta detekce nefunguje:

GPXSee: no upstream version found. - https://github.com/tumic0/GPXSee/tags - class="tag-name">([^<]*)</span

[.]

Já bych bral ty parníčky.