[Gelistirici] kararli depoya paket gecis sureci

[Ekin Meroğlu]

Merhaba;

Öncelikle, bu mailden önce bu (ve bir önceki) tartışmaya yazdığım maillere 
devam ediyorum büyük oranda, okumaya oradan başlarsanız sevinirim. 

Thursday 04 December 2008 tarihinde, Doruk Fisek şunları yazmıştı: 
> On hazirlik :
> 1) Bakıcısız tüm paketler işaretlenir.
> 2) Her bilesen icin birer bilesen sorumlusu secilir.

+1

> 3) Sadece güvenlik güncellemelerinin yapılacağı bir kaynak depo
> olusturulur. Guvenlik depo sorumlusunun, guvenlik takımından biri
> olması mantıklı olur sanırım.

Bu deponun daha öce yazdığım sebeplerle o sürümün bir branch'i olması 
gerekiyor, iki deponun arası açıldıkça neredeyse iki ayrı dağıtım haline 
gelecekler unstable depoyu bleeding-edge tuttukça. 

Depo sorumlusu ile güvenlik ekibinin çok buluşacağını sanmıyorum, bu depo ayrı 
bir dağıtım olmaya gittikçe depo sorumlusu daha yukarıdan büyük resme 
bakacak, depo sorunları ile uğraşabilecek bir geliştirici olmalı, güvenlik 
ekibinin işi başından aşkınken bu görevi ona vermek zor olabilir (aşağıda bu 
depocunun neden bazı işleri paylaşamayacağı da var..) 

> 4) Tercihen ayri bir guvenlik deposu derleme ciftligi olur. Burada
> yapilan tum degisiklikler guvenlik deposundaki paketlere gore
> derlenerek sisteme kurulur. "Kırılma" riski en aza indirilir.

Bu da tercihen değil, zorunlu - kullanıcıya ulaşan paket üretiyorsak sadece o 
kaynak depodan beslenen tamamen izole bir farm gerekiyor. Farm yeterince 
kırılgan ve elle işlediğinden sorun çıkarmaya açık bir adımı tüm sürecin, 
örneğin iki deponun aynı farmda derlenmesi gibi bir şey teoride mümkün olsa 
da öngöremediğimiz sorunlara yol açması kuvvetle muhtemel. Genelde de farmda 
çıkan hataların debug edilmesi uzun ve kafa karıştırıcı oluyor, depoya 
güvenlik güncellemesi yetiştirmeye çalışırken bu tip şeylerle uğraşmak 
zorunda kalmak saçları teker teker yolmak için birebir.

Ya da farm ve paket build yapısını tamamen değiştireceğiz - her paketin temiz 
system.base/devel + bağımlılıklarının kurulduğu bir chroot içinde derlendiği 
bir farm yapısı ilk aklıma gelen yol, ama bu __her__ şeyi değiştirmek demek.
  
> Sürekli düzenek :
> 1) Tüm geliştiriciler surum (2007, 2008, vb) kaynak svn depolarına
> erişip değişiklik yapabilir. Surum-guvenlik kaynak depolarına sadece
> güvenlik takımı insanları yazabilir.

Her geliştiricinin 2008 deposuna kommit yaptığı bir süreçte buildfarmı 
işlettim (2008 çıkmadan önceki süreçte) ve sonucunda amelelik olarak 
gördüğünüz, benim de svn merge kısmının büyük oranda hamallık olduğunu 
düşündüğüm süreci sevinerek işletir hale geldim - Farmı çalıştırdığınızda 
acil güvenlik güncellemesi paketinizin yerine openoffice derlerken bulmak, 
stable depoya almanız gereken paketin yeni -ve alakasız- güncelleme 
atarfından ezildiğini farketmek pek güzel tecrübeler değil. 

Aslında bunlar ve ve aşağıda farm derleme süreci hakkında söylediklerim 
birbirinin devamı : ben 2007 ve 2008 süreçlerinde aynı ofiste yüzyüze bakan 
adamların bu süreçleri birbirleri için nasıl zorlaştırabildiklerini ilk elden 
gördüm, daha çok hamallık yaparım ama sorunları çıktıktan sonra geriye dönmek 
zorunda kalmam bari diye düşündüm.

Merge sürecinin iyileştirilmesi için illa bu işin beş kişiye dağıtılması 
gerekmiyor diye düşünüyorum, bu yolda da konuşalım.

> 2) Her bileşenin sorumlusu, kendi bileşeninde yer alan paketlerde
> yapılan değişiklikleri takip eder. Gerekiyorsa müdahale eder, ilgili
> geliştiriciyi uyarır.

Bu en gerekli adım.

> 3) Her bileşenin sorumlusu, derleme çiftliğinde kendi bileşeninin
> paketlerini derletir[1] (ve test deposuna aktarılmasını sağlamış olur).

Bu pek yapılabilir değil bence : Farm paketleri derlerken tüm paketleri 
gözönüne alarak derleme ve kurma sırası çıkarmak, sonrasında yine tüm deponun 
tekrar oluşturulmasını sağlayıp belli kararlılık testleri yapmak gibi bir 
seri iş yapıyor, genelde de çıkan sorunlar tek bir bileşen çerçevesinde 
kalmıyor. Yani aslında depo yöneticisinin işin elle tutulan tarafını icra 
ettiği yer farm, her noktasını parmaklamak ve yaparken de kırıp dökmemek için 
fazlasıyla (çoğunlukla gereksiz) uğraşmak gerekiyor. 

Yukarıda söylediğim gibi tüm sürecin elle işletiliyor olması da ayrı bir 
sorun - ofiste temel olarak yeni buildfarm'ın denemelerini yapıp delta gibi 
yeni altyapıları geliştirdiğimiz ikinci bir farmımız var, yanyana masalarda 
oturan üç kişi olarak bile birbirimizin ayağına bastığımız oluyor - iki kere 
baştan kurdum o farmı. 
Daha otomatikleşmiş, farmcıbaşının müdahalelerine çok daha az ihtiyaç duyan 
bir farm yazılımı ile belki olabilir, ama paket ve depo üretmek fazlasıyla 
hata kaldırmaz bir iş olduğu için bu geliştirme ve test çalışmaları oldukça 
uzun sürüyor - sadece farm yazılımı değil, bir sürü temel teknolojide 
değişiklik gerektiriyor.

Bu dertli iş için bir köle yeter, beş kişiye aynı dertleri yüklemenin faydası 
yok diyorum yani.     

> 4) Güvenlik deposunun paketlerinin derlenmesi ve depoya aktarılması
> güvenlik depo sorumlusu tarafından yapılır.

Derlenmesi için bakınız yukarısı, yazma hakkı konusunda ise güvenlik için 
2007'de de, 2008'de de bu amaçla güvenlik ekibinden bir kişinin (zaten kaç 
kişiler ki :-)) yazma hakkı vardı (Önce İsmail, sonra Gökçen), 2008'e 
güvenlik ekibi olarak başlayan Gökçen kendi başına gökçen ekibi olup :-) 
Pınar'ı yalnız bırakınca Pınar'ı eklemek aklımıza gelmedi aslında. 

> 4) Güvenlik güncellemeleri test takımı tarafından hemen ve öncelikli
> olarak teste alınırlar. Hem surum-guvenlik hem de surum depolarına göre
> ayrı ayrı test edilirler.

Genelde test edilmeyecek kadar açık olmasını istiyoruz ama security dünyasında 
da ideallik pek gözde bir özellik değil - ayrı bir sec-test süreci tanımlamak 
iyi olur.
 
> 5) system.base bileşenindeki paketlerin testi yapılırken, "emniyet
> mandalı" nedeniyle sadece system.base guncellenmesi durumu da farkli
> guncelleme safhalarindaki Pardus sistem kombinasyonları ile test
> edilmelidir [2].
> [2] Guncelleme yapmak icin degil, sadece bir paket kurmaya kalkan bir
> kullanici zorunlu olarak (istegi disinda) sadece system.base
> guncellemelerini yapiyor. Tum sistemi yukseltmediginden dolayi
> bagimliliklardan dolayi problem yasiyor. Bu tur guncellemeyi "zorla"
> yaptirdigimizdan, hic problem yasanmamasi gerekir bu durumda.

Tamam bunu test edelim de burada verdiğin örnekte ya aynı şeyden 
bahsetmiyoruz, ya da başka bir sorun var -
Makinemde katapult kurulu değil, sistemim up-to-date değil, katapult kur 
diyorum : 

# pisi it katapult
Total size of package(s): 315.00 KB
Package katapult found in repository pardus-2008-test
katapult-0.3.2.2-12-2.pisi     (315.0 KB)100%    398.63 KB/s [00:00:00] 
[complete]
Installing katapult, version 0.3.2.2, release 12, build 2
Extracting the files of katapult
Configuring katapult package
Configured katapult
Installed katapult

ama depoda system.base güncellemesi var - hemen ardından :

mekbuk ekin # pisi up --dry-run
Updating repositories
* Updating repository: contrib
pisi-index.xml.bz2.sha1sum     (40.0  B)100%      0.00 --/- [--:--:--] 
[complete]
pisi-index.xml.bz2             (118.0 KB)100%      0.00 --/- [--:--:--] 
[complete]
No signature found for 
http://paketler.pardus.org.tr/contrib-2008/pisi-index.xml.bz2
* Package database updated.
* Updating repository: devel
devel repository information is up-to-date.
* Updating repository: pardus-2008-test
pisi-index.xml.bz2.sha1sum     (40.0  B)100%      0.00 --/- [--:--:--] 
[complete]
pisi-index.xml.bz2             (755.0 KB)100%    423.64 KB/s [00:00:00] 
[complete]
No signature found for 
http://yali.pardus.org.tr/pardus-2008-test/pisi-index.xml.bz2
* Package database updated.
Safety switch: Following packages in system.base will be upgraded: pisi
The following packages will be upgraded: pisi package-manager zpspell 
bash-completion gst-plugins-ugly gparted cups
Total size of package(s): 3.13 MB

Tek paket kurarken elle index güncellemediğimiz sürece güncellemeler gelmiyor 
bende ? 

> 6) CD içinde gelen paketler [3], ozel olarak gelistiricisi o paketle
> ilgili kendisinden onay alinmasini istemiyorsa, test deposuna girdikten
> 7 gun sonra test takimi araciligiyla test surecine alinir [4]. Bu
> surecten gecen paketler ilk toplu güncellemede kararli depoya aktarilir.

Bunu CD ile gelenler olarak tanımlamak ne kadar doğru ? CD ile bi ton sürücü 
de geliyor ama kullanıcıların bir bölümü hayatlarında ihtiyaç duymuyorlar 
onlara örneğin.

Aslında test adı altında konuştuğumuz her durumumdaki asıl dert kullanıcıların 
anlamlı bir bölümüne uydurabileceğimiz bir kullanım / güncelleme / kurulum 
senaryosu olmaması - her kullanıcı için ayrı (ve yeni) bir senaryo öncelikli 
oluyor - anlamlı test senaryosu sayısı (neredeyse) pardus kullancısı sayısı 
ile eşit. 

> 7) Test sürecinde yakalanan hatalar için Uluzilla'da bir hata raporu
> açılır ve paketi güncelleyen geliştiriciye atanır. Hata çözüldükten
> sonra süreç yeni paketle tekrar başlar (don't pass go, don't collect
> 200 gayme).

Geliştiricinin test deposuna gönderdiği pakette sorun olduğunu farkettiği anda 
kendine hata girmesi lazım - hadi bakalım :-?

> 8) CD içinde gelmeyen paketler test deposunda haklarında bir hata
> raporu açılmadan 7 gün zaman geçirirlerse [5] ilk toplu güncellemede
> kararlı depoya aktarılırlar.

7 gün yerine ilk önerin iki haftayı tercih edeceğim galiba.
 
> 9) Rüştünü ispatlanmış paketlerin test deposundan kararlı depoya toplu
> güncelleme işlemini ilgili depo sorumlusu her haftanın başında yapar.
> Güncellemeler girdikten sonra Turkce ve Ingilizce olarak depoya yeni
> giren paketleri ve niye yapıldıklarını e-posta ile yayinlar.

Burada yine bir gerekliği hatırlatacağım - bu güncellemeler depoya girerken :
- depoya eksik/kırık bağımlılık girmediği, 
- en azından bir önceki depo state'inde olan bir kullanıcının yeni state'e 
sorunsuz güncelleyebilir durumda olduğunu teste etmemiz gerekiyor - bu uzun 
ve ekip isteyen birşey değil, ama bu adıma kadar her sorunun çözülmüş 
olduğunu, burada bir hatayla karşılaşmayacağımızı kabul etmemeliyiz - örneğin 
yeni kernelle birlikte alınması unutulan bir sürücü depoyu güncellenemez 
halde bırakabiliyor. 

> 10) Pardus deposu için bu süreç oturtulduktan *sonra*, donanım ve insan
> gücü olanakları dahilinde contrib deposu için de uygulanabilir (bir test
> deposu oluşturmak, bileşen sorumluları belirlemek, vb). CD'de gelen,
> system.base ve benzeri paketler olmadığı için, Contrib deposunun test
> süreci sadece 8. maddeden ibaret oluyor elbette.

Bunu bilemiyorum, önemli olan istenip istenmeyeceği - ama stable / unstable 
kaynak depo ayrımı yaparsak contribin de bu şekilde dallanması gerekecek - 
yoksa yine contrib'i hangi depo üzerinde derleyeceğiz karmaşası çıkacak, ve 
bu sefer birbirinden şimdiki test-stable ayrımından çok  daha ayrı iki depo 
olacak.
 
> [1] Bunun kolay yapılabilmesi icin derleme çiftliğinde bazı
> değişiklikler gerekebilir elbette. Ama çok masraf ettirmeyeceğini
> umuyorum.

Ufak değişiklikler masraf çıkarmaz ama senin senaryoya uydurmak farm sürecini 
tamamen değiştirip oldukça otomatize etmek gerektiriyor, bu da kolay ve 
ağrısız bir süreç değil - tahminen bayağı uzun ve masraflı olur.

> [4] CD'de gelen paketler kullanicinin sistemine zorunlu olarak
> kuruldugundan ve ozellikle kaldirilmadiklari surece tum kullanicilarda
> guncelleneceginden ozel olarak dikkat edilmesi gerekiyor.

+1, ama bu özel dikkat biraz muallak, nasıl kağıda dökülür bilemiyorum - her 
paketin dikkat isteyen noktaları ayrı çünkü.

Özetle, çok başındayız, bu sürece karar vermek kendi başına uzun bir süreç 
olacak. Yapmamız elzem, ama hem karar hem uygulama sürecinde bu tartışmaların 
on katı gerekecek. Bence sorun değil uzun ve zor olması, ama tüm 
geliştiricilerin katkıda bulunup beyin fırtınası (ben beyin fırtınası gördüm) 
yapmadan imkansıza yakın.
--
İyi Çalışmalar;
Ekin Meroglu <ekin_at_pardus.org.tr>

... did i listen to pop music because i was miserable, or was i miserable
because i listened to pop music?... - rob [nick hornby / hi fi]