Realita je, že náš QA tým je složený z našich vývojář a vážněji míněného máme snad jen jednoho člověka na podpoře který pravidelně každý release prokliká. V takto velkém QA týmu jsme se vážně ještě nedostali k tomu, aby jsme sestavovali nějaké diagramy a soupisy. Obecně se zvednu a řeknu kolegovi ať to vyzkouší a jestli se s tím vypořádá. (připomínám že turris team je stále asi 25 lidí) Nenapadlo nás to dělat protože jsme to interně nepotřebovali, ale pokud bude komunita ochotná testovat a potřebuje to k tomu tak mohu navrhnout aby něco takového vznikalo. Z mého pohledu aktuálně je asi největší problém to, že uživatele prostě v nightly ani v rc skoro nemáme. Bohužel ale jak se zdá tak někteří uživatele za to, že budou mít router v nightly třeba chtějí podporu 24/7 a nejlépe na telefonu a jsme tam kde jsme byli kdy by jsme poskytovali službu na kterou nemáme kapacity. Pokud by i jen část aktivních uživatelů tady na fóru se do těch větví přeplo tak by nám pomohli opravovat chyby i měsíce dopředu. Myslím si, že to co ve skutečnosti chcete, tedy kompletní přehled změn, vám vlastně nabídne git a nebo naopak pak námi sepsané změny. Pokud chcete něco mezi tím, tak se obávám, že aktuálně na to nemáme moc čas i když je pravda, že by to pro některé pokročilé uživatele byl takový seznam změn přínosem. Za mě, jakožto za software updateru jsou třeba podrobnější změny popsány v changelogu verzí updateru. Možná je tedy řešením dát dohromady odkazy na to kde nalézt pokročilejší changelogy k našim programům? Pomohlo by to?
Samozřejmě toto by řešilo jen náš software. Změny v cizím softwaru mnohdy nemáme ale zmapované ani my, protože je přebíráme z lede (ano backportujeme balíčky aktuálně). Bohužel nejsme ani MS aby jsme si vše psali sami ani Red Hat aby jsme měli dostatek lidí aby jsme si takové zmapování udělali. Takže opět zbývá jen slepé testování tak jak to bylo doteď.
Poslední věc která by vám třeba mohla pomoci pokud vás zajímají změny například v přesunech souborů v našem softwaru tak můžete vzít dva různé medkity a porovnat jejich obsah (můžete porovnat verze balíčků a změny v cestách souborů. Změny v souborech, to je většinou všechno, protože nemáme reprodukovatelné buildy). Dokonce s updaterem si můžete vygenerovat vlastní medkit s vlastní konfigurací balíčků a tak by jste se mohl podívat přesně na to co se mění na úrovni mezi verzemi (samozřejmě s ohledem na balíčky, nehovoří to vůbec o tom jestli naběhne služba a podobně na to je třeba zase testování na hardware).
Ani jedno není asi dokonale to co jste měl na mysli, ale bohužel jak psal @RadoslavCap, aktuálně na to asi vážně nemáme kapacitu. Je tedy otázka jestli dokážeme najít nějakou metodu která Vám jako testerům pomůže a nám práci moc nepřidá.
Diky za vystiznou odpoved a snahu resit situaci Jinak mi prosim tykej, jsem jednim z ucastniku letosniho hackatonu a urcite jsme se jiz potkali, i kdyz jsem Mishkovi s portaci na Btrfs zrovna mnoho nepomohl…
Ale zpatky ke QA:
Rozumim, prepnu se tedy alespon do RC verze se svym Turris 1.1. Na nightly si netroufnu, jelikoz router nemam v dosahu, abych pripadne problemy mohl resit sroubovakem a moznym preflashovanim.
Bylo by mozne alespon soucasti kazde zpravicky o nove RC verzi taktez uvest odkazy na konkretni zmeny souboru v gitu? Pro vetsi prehlednost apod.
Troufam si rict, ze ano Cim vice informaci, tim mene se bude jednat o testovani blackboxu.
Dale by bylo fajn napsat alespon kratky popis, jak se ma nove implementovana ficura chovat a co vlastne dela, pripadne, kde najit nejaky jeji log. Coz by taky usetrilo testovani
Plne chapu, tady by snad pomohlo maximalne sjednotit podvozky Turris 1.x a Omnie, mysleno dostat oba typy na stejny kernel (v LEDE upstreamu jsem cetl neco o chystanem 4.14 LTS? ), konecne mit musl libc i na Turrisech 1.1 atd.
Mel jsem dojem, ze reprodukovatelne buildy se v OpenWRT prave nachazi! Neslo by se k takovemu prostredi opet vratit?
Podle me je resenim mit release jako ma linux - ve stable se delaji jen security patche a jednou za cas se vybere verze ze tohle je novy stable. Takovy release by mi vyhovoval a mohl bych router dat treba ke znamym a rodicum bez strachu ze neco nepujde.
OK přepnul jsem se na RC větev (branch SFSG (So Far So Good, jak říkává můj kamarád Minule jsem měl problém vrátit se na běžnou (“deploy”) verzi, doufám že snad tentokrát to nebude také Minimální konfigurace - WiFi & Ubuntu container
V nightly nemusí být podpora 24/7, stačí přes den Jsem velmi vděčný za to že si mohu užívat plody Vaší práce. Jak původní Turris tak Omina jsou skvělý hardware a baví mne se v tom šťourat a hrát si s tím. Pochopte ale jaký hardware vyvíjíte a dodáváte. Omnii dokonce komerčně. Bránu přes kterou se lidé a jejich rodiny připojují do internetu a na tom je spousta lidí dnes již dokonce i pracovně závislých, tedy je pochopitelné to rozladění, když se rozbije základní funkce. Pochopím že nejde suricata, honeypot, majordomo, pakon nebo nějaké specialitky, které si uživatelé doinstalují sami ze své iniciativy nad tím bych mávnul rukou a každému je jasné že i když je to nepříjemné, tak svět se nezboří když to pár dní nebude fungovat jak má. Ve 3.9 se ale povedlo to znefunkčnit celé včetně wifi i směřování do drátové sítě a tím úplně odříznout naše rodiny od internetu. OK může za to updater a cizí balíčky, koho by to napadlo. Zajímavé že to přišlo skoro přesně rok po průšvihu s ovladači od Candela technologies. Navrhoval bych v prosinci nenasazovat vůbec nic a nechat to až na leden. Myslím že nebudu mluvit jen za sebe že lidé mají v prosinci většinou úplně jiné starosti než řešit rozbitý turris. Pro sebe si z toho odnáším zkušenost že před odjezdem do zahraničí musím v turrisu zablokovat aktualizace protože se pak rodina nedostane na internet a já do vnitřní sítě do NASu když to náhodou budu potřebovat.
Zkusím možná po vánocích přepnout na nightly ale jakým způsobem Vám pak poskytnout zpětnou vazbu ? A kdo mi pomůže když se náhodou stane to že se to rozsype celé a navzdory rollbacku schnapps opět nebudu vědět co s tím ? Jak navrhujete nastavit komunikaci v takovém případě když poptáváte abychom Vám s testováním pomohli ? Rok jsem byl ve Windows Insider a testoval buildy Windows 10, které mají speciální aplikaci na feedback, která jde pŕímo na vývojový tým. Po roce jsem z toho ale musel vyskočit protože se s tím nedalo normálně fungovat někdy dorazil nový build jednou za měsíc a někdy každý týden, pokaždé to kompletně přetočilo veškeré systémové soubory windows což nějakou dobu trvalo a stálo to většinou 4 restarty. Několikrát jsem poskytoval zpětnou vazbu přes aplikaci mcrosoftu přímo vývojovému týmu a většinou to v dalším buildu opravili. S nightly budu ve stavu kdy se něco rozbije a já vůbec nebudu vědět co s tím ani na koho se obrátit a co je zrovna rozvrtáno. Psát na podporu, která řeší produkční verzi mi moc nedává smysl, proto jsem psal že by bylo fajn mít kontakt na někoho na koho se v takovém případě obrátit. Zkuste se zamyslet a něco tedy navrhnout. Na jednu stranu chcete abychom Vám pomohli a myslím že by se do toho i více lidí zapojilo pokud by ovšem cítili že v tom nebudou sami a že mají odpovídající podporu bez které mi to příjde trochu asymetrické. Říkáte že nemáte na to lidi no tak pak ale nevím co s tím asi se to tak nedá takto dělat.
Ještě mne napadlo, vezměte si příklad z firmy Synology a jejich NASů. Nyní dělají i router. Používají také linux a spoustu různých typů procesorů v jejich NASech přesto za 6 let co mám jejich NAS jsem nezažil, že by se ten hardware dostal do stavu kdy bych vůbec nevěděl co s tím. Testují v Beta verzích klidně i půl roku než s tím jdou do produkce. Jejich NASy vypadájí tak že za obrovskou raketu koupíte plechovou krabičku s plošným spojem na kterém je jeden čip a to je všechno. Pak si říkáte proč to stojí tolik. Teď už je to jasné, veškeré peníze jdou do vývoje a testování. Každý má možnost zapojit se do beta testování, ale všude výrazně upozorňují že nic negarantují a nedoporučují instalovat Beta verzi na produkční systémy. Několikrát jsem také kontaktoval jejich podporu, odpověď rychlá, přesná co kde udělat, případně bylo možné jim udělit přístup na vlastní hw pro analýzu a opravu. Možná by si @Tangero mohl udělat cestu na Taiwan a navštívit jejich centrálu kde se nachytřit.
Bylo by zajimave zjistit v nasem nejmenovanem velkoobchode s elektronikou, kolik zakazniku uz jim tam prineslo Omnii k reklamaci. Ja si nedovedu predstavit, ze kdybych koupil tak drahy kus hardwaru a on me po case prestal fungovat (kolik normalnich uzivatelu vubec vi o tomhle foru/ je ochotno, schopno se v tom sami vrtat a zna pricinu umrtveni routeru), tak to popadnu a jdu reklamovat k prodejci. Stejne jako kazdou jinou vec. Mozna by bylo dobre pribalovat k Omnii nejaky levny routrik jako pojistku pro pripady nefunkcnosti, aby domacnosti nezustavaly bez internetu. Do te ceny by se jiste vesel.
Jeste by mne zajimala jedna vec. Pro mne jako uzivatele modraska 1.1 byla nadejna migrace na BTRFS. Myslel jsem, ze pomoci chnapsu se v pripade problemu snadno vratim k posledni funkcni verzi. Jak to tady ale ctu, ani to ted nefunguje. Jak to tedy je?
Co vím tak na té SD kartě kam se migruje na BTRFS je několik partition a bootuje se z té první ve které je uložen kernel, kterou ale schnapps rollback neovlivní. A pokud dojde k tomu že se neaktualizuje ta první partition ale moduly pro jinou verzi zůstanou na té s BTRFS tak se pak stane to o čem píšu a sice to že se to celé rozsype.
Plně s vámi souhlasím. Provozuji NAS od Synology cca 5 let a mám s nimi výbornou zkušenost. Koupil jsem si Omnii s představou, že její spolehlivost bude obdobná. Bohužel tomu tak není a tak se s každým dalším nepodařeným update Omnie posouvám k nákupu Synology routeru…
[quote=“homberg, post:84, topic:5941, full:true”]
Bylo by zajimave zjistit v nasem nejmenovanem velkoobchode s elektronikou, kolik zakazniku uz jim tam prineslo Omnii k reklamaci. Ja si nedovedu predstavit, ze kdybych koupil tak drahy kus hardwaru a on me po case prestal fungovat (kolik normalnich uzivatelu vubec vi o tomhle foru/ je ochotno, schopno se v tom sami vrtat a zna pricinu umrtveni routeru), tak to popadnu a jdu reklamovat k prodejci. Stejne jako kazdou jinou vec.[/quote]
No ale pokud nejsou ochotni/schopni se v tom vrtat, tak pouziva jen jednoduchou konfiguraci a tudiz nenarazi na zadne problemy. Co lidem obcas rozbijeme sou exoticke konfigurace a workflow
Nemyslím si, že je dobré dělat kompletní přehled změn z gitu, to by vedlo na hodně dlouhý příspěvek a moc práce. Ale můžeme přikládat odkaz do gitlabu na commit který jsme do rc releasly (poznámka: to samé můžete udělat i teď pomocí souboru git-hash z repo.turris.cz). Jen se obávám, že to není co úplně chcete, protože změny v gitu nic moc neříkají o změnách na routeru pokud neznáte openwrt build systém.
U nových featur to většinou děláme, jen to většinou není vydané v době rc (třeba panoň). Asi bychom si mohli dát za cíl dokumentaci dostat ven už s releasem prvního rc. Problém je většinou, že jak se zdá, tak občas nastane situace, že uživatel vnímá jako novou featuru něco co vývojář bere jako refactorizaci. V takovém případě nám to prostě nedojde a musíte nás na to upozornit, jinak to nejde.
Oba routery máme na stejném kernelu a nad 4.14 také uvažujeme. V případě musl, ten už na Turris 1.x měl být, ale ukázalo se, že se jedná o velké množství práce (opatchovat software pro powerpc a pod) které už v lede je a tedy přechod bude uskutečněn společně s 4.0. Ano jedná se o věci na kterých aktivně pracujeme a jedná se o naši prioritu, protože jinak se nám systém rozpadne pod rukama zcela.
Promiňte, ale tímto jste mě pobavil. Ne openwrt nemá k reprodukovatelným buildům ani nakročeno. Ba co víc, jde proti standardním postupům jak se buildí distribuce které jsou praktiky standard kdekoliv jinde, které vedou na naprosto nedetekovatelné fatální chyby. Krásným příkladem je tiché zahození balíků pro které se mu nepodařilo vyřešit závislosti. Nebo třeba to, že pokud něco zkompilujete součástí celého buildu a mimo něj (po něm) tak dostanete klidně aplikaci která je slinkovaná proti jiným knihovnám než má závislosti a to vše samozřejmě bez varování. Takže taková malá změna kdekoliv může vést na změnu pořadí kompilace která vede na chyby v balíčcích na které se rok nesáhlo a ani nejsou chybně. Takže ne, openwrt nemá reprodukovatelné buildy.
V adresářích pro různé modely a větve je vždy soubor git-hash ve kterém je hash commitu který byl použit pro sestavení této větve. Díky němu si může kdo chce přesně najít který commit jsme buldili z gitu. Samozřejmě nevýhoda je, že jednotlivé verze rc nearchivujeme a tak ani vlastně sami nevíme přesně které rc bylo na kterém commitu (jediné co platí je, že se jedná a commity které jdou po sobě. No i když to, že to nevíme to není úplně pravda, přistane nám to v emailu). Ale v důsledku takto můžete zjistit co je v daném stromě zkompilováno i když jsme to ještě nevydali a tedy nevytvořili tomu tag (samozřejmě pro vydání do deploy se v gitu objeví tag).
Zmiňují, že se o to snaží. To je asi i pravda, na OpenWRT summitu se o tom zmíní někdo každý rok. Ale můj názor je, že vlastně nikdo nemá čas a nebo neví za jaký konec za to vzít. Jak jsem psal, před tím než se v openwrt budou schopni zabývat věcmi jako reprodukovatelné buildy tak musí vyřešit mnohem vážnější problémy. Jedním z nich je třeba nekonzistence v závislostech (aktuálně na to používají tři různé nástroje ve který nejde dohromady popsat vše, kconfig, make a opkg), dále třeba to že buildy jsou vždy nad stejným rootem který neodpovídá striktně závislostem a automatické configure skripty tak někdy zapínají to co nemají v závislosti v jakém pořadí se balíčky buildí a je toho mnohem více. Prostě to není procházka růžovým sadem jak se může občas zdát.
Diky moc za objasneni. Pri testovani dalsi RC verze, se na git vice zamerim.
nemam o tom nejmensich pohyb, ze se na to pracuje.
Panove, diky za priblizeni a poodkryti zakulisi. Vidim, ze je zde jeste kupa prace. Kdyby byla potreba pomoct napr. s kompilaci novych balicku, nebo podobnymi vecmi, rad prilozim ruku k dilu.
Jinak mi prosim tykej, jsem jednim z ucastniku letosniho hackatonu a urcite jsme se jiz potkali, i kdyz jsem Mishkovi s portaci na Btrfs zrovna mnoho nepomohl…
Minimální konfigurace - WiFi & Ubuntu container 
nemam o tom nejmensich pohyb, ze se na to pracuje.