[OBM Admin] Fw: updatek menete

[Bán Miklós]

Kedves projekt adminok,

Kovács Istvánnal megy itt egy levelezés, ami mindenkit érint, ezért
áthozom ide privátból a beszélgetést.

Arról van szó, hogy átláthatóbb keretek közé próbáljuk terelni a
fejlesztést, hogy kevesebb bug kerüljön ki a szerverekre.

Ha van bárkinek javaslata, jöhet!!


üdv, Miki



Begin forwarded message:

Date: Tue, 7 Aug 2018 11:32:46 +0300
From: Istvan Kovacs <istvan.kovacs at milvus.ro>
To: Bán Miklós <banm at vocs.unideb.hu>
Cc: "gabor.bone at milvus.ro" <gabor.bone at milvus.ro>
Subject: Re: updatek menete


Szia

Van egy részleges javaslatom. Ehhez azonban leírom még egyszer 
egyértelműen a problémákat, amiket látok.
1. Az új fejlesztések miatt, amik félkészen a főágban vannak, nem
tudjuk a javításokat updatelni.
2. Az új fejlesztések bekerülnek a végleges updatekbe anélkül, hogy 
erről lenne bármiféle előzetes egyeztetés, egyértelmű kommunikáció
lenne ezzel kapcsolatban felénk, adatbázis adminok felé, és anélkül,
hogy megfelelően lennének tesztelve. A fejlesztések egy részéről nem is 
tudok, mert nem értem azokat a nagyon szűkszavú mondatocskákat amik, a 
GIT-es kommitekbe írtok.

Javasolt megoldások:
1. Az első problémára nem tudok tehnikailag megoldást javasolni, mert 
nem látom át, hogy mit és hogy lehet. De egyértelműen valahogy úgy kéne 
csinálni, hogy a fejlesztések külön menjenek, a javítások pedig külön.
A javításokat be lehetne tenni a főágba, így bármikor lehet őket
updatelni javítva a hibákat, a fejlesztések egy mellékágon kéne
fussanak, amíg nem jutnak el a megfelelő szintre. Azaz gyakorlatilag a
fejlesztések a ti esetetekben is csomagonként kéne a főágba kerüljenek.


VÁLASZ:
 Technikailag megoldható, némileg több odafigyelést igényel, de át
 tudunk állni egy master-testing ágba ahova a véglegesbe szánt
 fejlesztéseket szánjunk. A masterba csak hotfixek mennek, amikor meg
 mehet a következő master (le lett tesztelve), akkor rebassel képezzük a
 master-testing-ből.




2. A fejlesztések tesztelésére és előzetes megnézésére, megtárgyalására 
az adatbázis adminok által megoldás lehetne, ha létrehoznál egy 
tesztadatbázist (függetlent az OpenBiomapstől vagy mástól), ami csak
ezt a célt szolgálná. Oda minden adatbázisból minden funkciót be kéne
tenni. A felhasználók az adatbázis adminok lennének, minden felhasználó
admin lenne ebben, csináljon formokat, tegyen adatokat és teszteljen.
Amikor úgy érzitek, hogy egy fejlesztést befejeztetek a részetekről,
akkor azt ÉRTHETŐEN LEKOMMUNIKÁLJÁTOK az adminok felé és felteszitek
ebbe a teszt adatbázisba. Aztán lehetne egy kb két hetes határidő a
tesztelésre, a tesztelés után a javítások, módosítások, utána újra
tesztelés határidővel. És ez után kerüljön csak be a főágba.

VÁLASZ:
 Nekem tetszik ez az ötlet, talán nem túl bonyolult megcsinálni. Az
 ELTE, vagy a tintanyul szerver erre jó lenne. Ez utóbbiba diszk kell,
 mert lekapcsoltuk egy éve kb. Az előbbibe csak külső hozzáférést kell
 kérni az ELTE tűzfalon keresztül és fel kell a mostani állapotra hozni
 a rendszert....
 



Valami ilyesmiben kéne gondolkodni, de a probléma sűrgös megoldást 
igényel. Szóval megkérlek foglalkozzatok vele.

Üdv
I

On 06.08.2018 17:30, Bán Miklós wrote:
> Sziasztok,
>
> alapvetően egyetértek, tényleg elég önhatalmúan csinálom a dolgokat.
> Jogos a kritika. Gáborral már beszéltük is, hogy mindketten vegyük
> komolyabban a Master-branch használatát. Azaz oda tényleg csak
> tesztelt, kipróbált dolgok menjenek. Ezt már el is kezdtem alkalmazni.
>
> Javaslatok jöhetnek az összehangolsára, esetleg kitehetjük ezt a
> beszélgetést a devel listára. Hosszabb Skpye beszélgetés nem jó
> a héten mert utazunk és dugig van a hét feladatokkal....
>
> üdv, Miki
>
>
>
>
> On Mon, 6 Aug 2018 14:32:47 +0300
> Istvan Kovacs <istvan.kovacs at milvus.ro> wrote:
>  
>> Szia Miki,
>>
>> A héten, ha lenne időd feltétlenül kéne beszéljünk egy kicsit a
>> fejlesztések és az updatek menetének mikéntjéről, mert nagyon kezd
>> necces lenni a dolog. Ez a jelenlegi rendszer nem tartható, ugyanis
>> amikor valahogy sikerül összehozni egy updatet, mindig vannak
>> kritikus, nagyon otromba hibák benne (legutóbb a cache probléma, da
>> azelőtt is volt és azelőtt is). Egyrészt ezeknek egy része (tudom,
>> hogy nem az összes) nagyon gyorsan elő szokott jönni, ami sajnos azt
>> jelenti, hogy a minimális tesztelésre sem szokott sor kerülni.
>> Másrészt te mindig rögtön nekifogsz dolgozni valami egyében, és
>> eközben javítod ki a hibát. De minden be van kommitelve a Githubra,
>> emiatt, hiába javítod az előző kritikus hibát, mert updatelve csak
>> további hasonlók keletkeznek vagy félkész, nem jó megoldások kerülnek
>> az adatbázisba.
>>
>> Bevallom, hogy azt sem élvezem nagyon, hogy eddig működő megoldásokat
>> olyanokra cserélsz néha, ami nem olyan jó vagy összezavarja a
>> felhasználókat. Erre példa a minapi autoskippes módosítás a
>> feltöltéseknél. Most például emiatt húzzuk az updatet, mert ez nem jó
>> megoldás. Amúgy egyetértek, hogy azon a rendszeren is jó lenne
>> javítani, amit viszont hiányolok az az, hogy nincs rendesen
>> végiggondolva és nincs egyáltalán lekommunikálva az adatbázisokat
>> vezető személyekkel. Márpedig nem minden adatbázisnak jó minden
>> változtatás, lehet bizonyos dolgok opcionálisak kéne legyenek. Az
>> előzetes és fejlesztés közbeni egyeztetés pedig garantáltan segítene,
>> még ha lassítaná is a dolgokat.
>>
>> Nem tudom, hogy más adatbázis adminok hogy viszonyulnak ezekhez a
>> problémákhoz, de sejtem, hogy ott, mivel nem cél a külső emberek
>> meggyőzése, kevésbé érzékenyek erre. De az OpenBirdMapset ez meg
>> fogja szépen ölni. Azt a kevés külsőst is hamarosan elveszítjük, aki
>> eddig töltögetett. Egyszóval ezen sűrgösen változtatni kell.
>>
>> Ajánlanám, hogy a héten beszéljünk egy nap, mert erre mindenképpen
>> megoldást kell találni. Remélem sikerül.
>>
>> Üdv
>> István
>>
>>  
>
>  



-- 
Miklós Bán, PhD
MTA-DE "Lendület" Behavioural Ecology Research Group
Department of Evolutionary Zoology, University of Debrecen
H-4010 Debrecen, Egyetem tér 1.
Phone:  +36 52 512-900 ext. 62357
http://zoology.unideb.hu/@Miklos_Ban
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~