[Gelistirici] kararli depoya paket gecis sureci

[Doruk Fisek]

Merhaba,

Tue, 2 Dec 2008 12:28:31 +0200, "Furkan Duman" <coderlord at gmail.com> :

> Doruk affedersin dikkatimden kaçmış bu e-postaların. :(
> Acaba ayrı bir başlık açarak bu önerilerini yazsan nasıl olur? Belki
> diğer arkadaşların da dikkatinden kaçmıştır.

Seni kiracagima kafami arsiv fareligi yaparim :). Icinde sadece "test"
kelimesi gecenleri taradim yazdiklarimdan, baska aradan kacanlar olmus
olabilir.

22 Ekim'de yazdigim e-postada [1] iki farkli oneri yer aliyor. 8
Ekim'de yazdigim bir e-postada [2] baska bir oneri var. 5 Ekim'de
yazdigim e-postada [3] bir seri daha. 20 Mart'tan bir bukle [4]. 14
Mart'in ne eksigi var, hem de tip bayrami [5]. 4 Mart'ta bisiler daha
[6]. 30 Ocak'ta gelistirici toplantisinin(!!) ardindan onerilerimin posa
kivaminda ozeti [7].

Artik 2007'ye gecmeyeyim dedim, tarihte geriye gittikce yazdiklarimin
uygulanma yuzdesi artiyor ;). Ozan'in da dedigi gibi zamanla bazi seyler
"olgunlasiyor".

Bazilarinin "test sureci ile ne alakasi var canim" diye
dusunebilirsiniz. Aslinda oldukca ilgili, cunku bircok sav
"guncellemede sorun cikiyor" noktasina gelip dayaniyor. Bunlarin hepsi
de guncellemelerde sorun cikmasinin nedenleri ile ilgili.

Herhangi biri icin "x onerisinin ne oldugu anlasilmiyor, daha detayli
aciklar misin" diyene usenmeyip anlatabilirim.

- dfisek


=======

[1] http://liste.pardus.org.tr/gelistirici/2008-October/013904.html

"Bastan beri soyledigim gibi, test sureci ile kurunun yaninda cok fazla
yas yakmaya calisiliyor gibime geliyor. Sorun cikarip ortaligin
karismasina yol acan belli paketler var. Onlari belirleyip, onlarin
guncellenmesinde testlere ekstra ilgi gosterip, kalanlara sadece temel
testleri (paket menuye yerlesiyor mu, aciliyor mu) uygulamak daha
fizibl olur.

Daha da fizibl oldugunu dusundugum soyle bir radikal onerim var :

1) Sadece guvenlik guncellemelerinin yapildigi bir 2008 deposu olsun.
Bu depoya giren her guncellemede tirnagina kadar tum yazilimlar testten
gecsin. Bu depoya "kararli" olacak densin. Bir paket patlarsa test
takimini dovelim :)

2) Normal depoda test sureci islemesin ya da sadece kritik paketlerde
islesin. x hafta test deposunda durup hata raporu almayan paketler
normal depoya sorgusuz sualsiz girsin. Kullanicilar "sistemim bozuldu,
guncellemeler test edilmiyor mu" dediginde de, "test deposunda x hafta
hata belirtilmemis. eger surecin daha iyi olmasini istiyorsaniz, siz de
testlere daha cok katilin. Ben sistemim kararli kalsin istiyorum
diyorsaniz, sadece guvenlik guncellemeleri yapilan depoyu kullanin."
densin.

Boylece hedef belirlenmis olur, dagitim depolarinin bir kimligi olur.
Su anda bence herkes farkli beklentiler icinde dagitimdan ve kimse
mutlu olamiyor. Hem ultra kararli olayim, hem gelismelerden geri
kalmayayim, hem o da olsun, hem bu da olsun diye hareket edince hicbiri
elde edilemiyor.

Bu ilk defa yapilan bisi degil, Debian stable ve testing var. Pardus'un
surum cikarma dongusunun Debian kadar uzun olmadigi dusunulurse,
Debian'daki zararli yan etkiler de Pardus'ta cok az olacaktir diye
dusunuyorum."

=======

[2] http://liste.pardus.org.tr/gelistirici/2008-October/013773.html

"Su anda yuruyor ama nasil yurudugu belli degil. Cunku herkesin test
surecinden farkli beklentileri var. Oncelikle test surecinin ne artilar
katmasi gerektigi konusunda tum (cekirdek) ekip bir hemfikir olmasi
gerekiyor."

=======

[3] http://liste.pardus.org.tr/gelistirici/2008-October/013685.html

"Cozum ne?

1) Test surecinin "ciddi" yapilmasi. Ornegin her hafta Pazartesi gunu
test surecinin yeni gelen paketler icin tekrar baslanmasi gerekiyor.
Boyle bir insan gucumuz yok deniyorsa -- bunun adi konur, sadece belli
kritik paketlere test sureci uygulanabilir, kalanlar test edilmeden
depoya alinabilir.

Test edilmeden Pardus deposuna hic paket giremez deniyorsa,
insangucunun yetmedigi kalan paketler contrib deposuna alinmali. En
azindan adam gibi guncellenirler.

Ama bunun adi mutlaka konmali. Su anda "ne guzel de test yapiyoruz" diye
dusunenler kendilerini kandiriyorlar bence.

2) Bir "acil test ekibi"nin olmasi gerekiyor. Yani bir guvenlik
guncellemesi varsa, onu atiyorum 12 saat icinde test edip "tamam, bu
saglam" diyecek birileri olmali. Yanlis anlamayacaginizi umarak
soyluyorum, cekirdek ekipte az sayida insan yok, mesailerinin bir
kismini buna ayirmalari cok zor olmamali.


Bir de su anda cok kullanilan uygulamalar kirilmis durumda, 24 saat
gecmesine karsin hala cozum icin bisi yapilmamis durumda. Bu bir tek
bana mi batiyor bilmiyorum. Tatil gunu diyeceksiniz, dogru, o zaman
tatil gununde kritik guncelleme depoya almayalim :/"

=======

[4] http://liste.pardus.org.tr/gelistirici/2008-March/011497.html

"1.0 doneminde kullanilan, adi konmasa da 2007'deki merge/review
surecleri ile fiilen anlami yitirmis bir "bilesen sorumlusu" kavrami var
(her bolumde component.xml'de yazan kisi).

Bunu 2008 ile beraber tekrar hayata gecirmek bence iyi olurdu. Ilk
paket yapmaya basladigimda cok yararini gormustum. Atiyorum bir
kutuphane paketi yapacagim zaman, "bu resmi depoya girer mi", "boyle
bisiyin paketini yapmak anlamli mi", "hedede problem cikti, icinden
cikamiyorum, ne yapmaliyim" gibi sorulari birebir sorup yanit
alabilecegin bir kisi olmasi oldukca yararli oluyor. Su anda ilgili
bilesenin butununu goren insan olmadigi icin, hedede problem yok ama x
hodonun paketi onunla konusman lazim seklinde pinpon topuna
donebiliyorsun bir anda.

Mevcut politikada her paket kendi basina degerlendiriliyor, bulundugu
bilesen butunu icinde degil. Merge eden kisinin ya da test eden kisinin
tum guncellemeleri hakkini vererek test etmesini beklemek oldukca
hayal. Ayni bilesendeki baska programlari nasil etkiledigini
bilmesi biraz sansa kaliyor.

Onun yerine her bilesenin sorumlulugunu birine verip, kendi bilesenini
supurmesini beklemek cok daha verimli bir davranis olur gibime geliyor.
O kisi kendi bileseninde uzmanlasip, "ne paket olsa bakarim abi" diyen
insandan daha fazla ilgi gosterebilir. Depo "bol-yonet" politikasi
gutmeden yonetmek icin fazla buyuk diye dusunuyorum.

Bilesen sorumlusu kendi bilesenine girecek olan yeni paketin depoya
girip girmeyecegine karar verebilecegi gibi, paketin guncellenmesi
(merge) islemi/karari da bilesen sorumlusuna verilebilir. Insanlarin
uzerindeki yuku azaltacagi gibi, farkli kisilerin sorumluluk almasini,
kendini gelistirmesini ve yetismesini saglayacaktir. Ileride
gerceklesecek gorev degisimlerinde "hazir" daha fazla insan da olur
boylece.

Benden duramayip ortaya atilan bir 2ykr daha."

=======

[5] http://liste.pardus.org.tr/gelistirici/2008-March/011431.html

"Su anda bir paketi guncellemek isteyen once devel'de bunu yapiyor, ayni
mesajin neredeyse bir kopyasini stable listesine atarak 2007'ye merge
isteginde bulunuyor. Merge'cu basi alip onu 2007'ye aktariyor (bir
mesaj daha). Sonra derleme ciftliginin basindaki insan ciftligi
durtuyor, paketler derleniyor ve test deposuna giriyor.

Cok uzun zamandir, stable'a yapilan bir merge istegine, yav bu
guncelleme cok sacma, bunu yapmayalim diyen olmadi. Boyle bir sey
denecek olsa, zaten 2007 commitlerine bakilarak da soylenebilir. "Geri
al" denir, alinir. Zaten otomatik olarak derlenmiyor ki paketler,
derleyici basi durtuyor paketleri. Yine bir elle mudahale/engelleme
asamasi mevcut. Otomatik olarak hatali bir paket girmesi soz konusu
degil.

Hadi diyelim ki tum bu asamalari gecti, insanlarin gozunden kacti, o
paketin girip girecegi yer test deposu. Direk kararli depoya girmiyor
ki.

Resmi depodaki bir paketin sorumlulugunu ustlenen bir adama o kadarcik
da guvenmiyorsak (atlama durumunda guncellemesinin test deposuna
aktarilabilmesi olasiligi), niye paket veriyoruz ki eline?

Ustelik 2007 ile devel arasindaki ucurumun artmasi nedeniyle olay kafa
karistirici bir hal de aldi. "Paketteki onu al, bunu alma" yapmaya ya
da playground'dan al demeye basladik.

Yanlis anlama, bana uzaktan, merge yapan adam bildigin amelelik yapiyor
gibi gozukuyor. Belki sistemin temel bilesenlerinin sik guncellendigi
ilk donemlerde, gelistiricileri gemlemek icin iyi bir mekanizmaydi. Su
anda anlamsiz bir burokrasiye donusmus durumda. Hem paketini
guncelleyen, hem de o paketi merge eden icin."

=======

[6] http://liste.pardus.org.tr/gelistirici/2008-March/011353.html

Tue, 4 Mar 2008 11:16:55 +0200, Serbülent ÜNSAL
<serbulent at pardus.org.tr> :

>         1-  n adet güncelleme belirli bir sayıya ulaştığında veya
> ACK/NACK sorumlusunun (A/N sorumlusu olarak geçecektir) uygun gördüğü
> bir zamanda ACK/NACK listesine dahil edilir.
Eger bu sekilde bir ek prosedur eklendiyse, bu surecin paket sayisi ya
da can cekmesinden bagimsiz bicimde daha sik islemesi gerekir. Ornegin
her hafta basi gibi.

Zaten paketci "ACK" vermeden once paket bir sure test deposunda
geciriyor. Bu prosedurle bir paketin kararli depoya girmesi bir aydan
bile fazla surebilir.

****

Ek olarak paketlerin hepsini esit kabul etmek cok anlamli degil. Baska
hicbir pakete bagimli olmayan, guncellemesi baska bir uygulamayi
bozmasi mumkun olmayan paketler var. Bunlarla baska paketleri
etkileyecek paketlerin guncelleme sureclerini birbirinden ayirmak
gerekir.

=======

[7] http://liste.pardus.org.tr/gelistirici/2008-January/010756.html

"Hedeflerle uyumlu bir teknik politika guduldugune emin misiniz peki?

Gelistirici toplantisinin katilmadiginiz bolumunde, bu konudaki
sorunlarin nedenlerini ve olasi cozumleri soylemistim. Aslinda katilan
diger arkadaslara sorup ogrenin, ben bir daha neden anlatayim demek
isterdim ama sonra (tekrar) anlatsaydim farkli olur muydu diye
dusunmemek icin yaziyorum. Anca posasi olacak ama idare edin.

Pardus Projesi'nin su anda bir kismi yari zamanli olan 14 tane calisani
var (toplantida soylendigi kadariyla). Bu projeden beklentiler benim
disaridan gordugum kadariyla sunlar :

1) Bir Linux dagitimi cikarsin.
2) Dagitimi elalemin degil, kendi gelistirdigi araclarla cikarsin.
3) Ozel projelerin pesinde kostursun (MSB, UEKAE, vs vs).

Bu siralamayi birbirine bagimlilik sirasina gore yazdim. Dagitimin
kendisi olmadan kendi gelistirdigin araclar bir ise yaramaz, dagitim
olmadan onun uzerine ozel proje gelistiremezsin.

Dagitimin ana parcalari (toolchain, X ve diger donanim destekleri, KDE,
multimedia araclari) bu 14 kisinin 4 kisisinde (Caglar, Ismail, Onur ve
Fatih) toplanmis durumda (bu 4'ten biri de yari zamanli). Bu sayi uzun
sure 3'tu, birkac ay once 4'e cikti.

Sorun Loker'in soyledigi gibi upstream'le halay cekmekten degil, tam
tersine upstream'le yeterince halay cekmemekten kaynaklaniyor.
Dagitimdaki ilgili yazilimdan sorumlu kisinin yapmasi gereken, yazilimi
gelistiren yazarlar (upstream) ile dagitim kullanicilari arasinda kopru
gorevi gormek -- yani dagitim kullanicilarinin farkettigi hatalari
onlara aktarmak, cozulmesi icin onlari zorlamak ve daha sonra cozumleri
dagitima entegre etmek.

Son donemlerde ozellikle Caglar ve Ismail'in sorumluluklarini aldiklari
yazilimlarin hakkini veremediklerini gormek icin kahin olmak
gerekmiyor. Disaridan bile acikca gorunuyor bu. Bunun yani sira
Erdinc'in uzerinde olan ve kendisinin dogal olarak projede profesyonel
olarak calistigi zamanki kadar ilgilenmedigi dunya kadar yazilim var.
Ancak aylardir bu -bilinen- sorunlarla ilgilenilmiyor, "bekledikce"
gececegi umuluyor ve bunun sonucu da calismayan bluetooth destegi,
kirilan x yazici destegi, calismayan ati ekran karti, bozuk flash
eklentisi olarak kullaniciya donuyor. "Yazilim bozmayalim" demek lafta
kolay, pratikte ise ciddi calisma ve emek isteyen bir is. Gerekli
calismayi yap(a)mayinca da sonuc bu oluyor.

Cozum... Daha fazla adam almak ya da "ne kadar ekmek, o kadar kofte"
demek olabilir.

Elimizdeki olanaklar bu, bununla yapmamiz lazim diyorsaniz bu isi, o
zaman 4/14'luk oran cok acayip. Dagitimin "olmazsa olmaz" bilesenlerini
dagitim calisanlarinin 1/3'unden bile az bir kitle hazirliyor demek.

Burada Pardus dagitiminin amaci ne sorusunu sormak gerekiyor. Hedef
kitle gercekten bilisim okur-yazari kitleyse burada ciddi bir
oncelikleme sorunu var demektir. Bu kitlenin 5 tane ses kartinin daha
Pardus'ta duzgun calismasini, Pisi'ye rollback ozelligi eklenmesinden,
Yali'nin Qt4'e port edilmesinden ya da yeni Kaptan yazilmasindan daha
cok onemseyecegini dusunuyorum.

Yali'ya, Kaptan'a, Pisi'ye yeni bir ozellik eklemeden de bir 2008
dagitimi cikarabilirsiniz. Biraz sıkıntı cekilir ama gene de olur. Bu
yazilimlarin entegre etmesi beklenen dagitimin temel parcalari olmadan
ise ortada dagitim diye bir sey olmaz.

Daha soylenesi cok sey var ama bende guc kalmadi. Eksikleri toplantinin
o bolumunde olan calisma arkadaslarinizin doldurmasini rica edin
lutfen."

=======