[Gelistirici] kararli depoya paket gecis sureci

[Ozan Çağlayan]

Doruk Fisek wrote On 04-12-2008 18:05:
> On hazirlik :
> 1) Bakıcısız tüm paketler işaretlenir.
> 2) Her bilesen icin birer bilesen sorumlusu secilir.
> 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.
> 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.
>   
Sadece güvenlik güncellemelerinin yapılacağı bir depo demek, bir 
dağıtımı geride birakıp diğerini geliştirmeye tekabül ediyor. Örneğin 
Ubuntu yeni sürümü çıkardığı anda, o sürüm güvenlik ve bugfix dışında 
güncelleme kabul etmiyor ve asıl bleeding edge geliştirme yeni depoda 
devam ediyor.
200x çıktığı T anında, 200x'in güvenlik güncellemeleri dışında bir şey 
kabul etmemesi onu benim bakış açımda ayrı bir sürüm haline getiriyor.

Olay sadece kararlılıksa,
1. 2007 sürümünde kalır,
2. 2008'e geçer ama sadece güvenlik güncellemelerini yapar.

2.seçenekle senin önerdiğinin arasında bir fark bulamadım ben. PiSi de, 
paket yöneticisi de bu özelliği sağlıyor zaten. Adama yeni bir depo 
ekletmek yerine paket yöneticisi ayarlarından "Sadece güvenlik 
güncellemelerini yap" seçtirmek bu işi halletmiyor mu?

Ayrıca 2000 civarı kaynak paketin bir kısmı dağıtım çıktıktan sonra, bir 
kısmı önce, kimi paldır küldür kimi özenle 2008'e merge edildi. 2008'in 
çıkmasının üzerinden 6 ay geçti geçecek, hala şu ana kadar(sandbox 
sızmaları yüzünden) aslında hiç çalışır durumda olmamış paketler 
yakalıyoruz depoda. Sadece güvenlik güncellemeleri yapıyoruz bu depoda 
diyeceksek, o depodaki 2000 küsür paketin tam takır çalıştığını taahhüt 
etmemiz gerekiyor. İdeal dünyada etmeyi hepimiz isteriz o ayrı mesele.
> 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.
>   
Tüm geliştiricilerin sürüm kaynak svn depolarına erişip değişiklik 
yapmalarını doğru bulmuyorum. Sürüm kaynak svn deposunda değişiklik 
yapıldığı anda o paket farm'da bir sonraki çalışmada derlenecek paketler 
arasına giriyor. Arada hiçbir kontrol mekanizması yok. Eğer bu 
bahsettiğin adım, Merge işlemini ortadan kaldırmayı hedefliyorsa 
gerçekten çok büyük sorunlarımız olur. Hiçbirimiz mükemmel değiliz, hata 
yapıyoruz. Senin düzeneğinde bu depolar kararsız(normal) depoya işaret 
edeceğinden çok fazla problem olmayabilir gibi gelse de kararsız ile 
kullanılamaz'ı ayırt etmek lazım. Yepisyeni review'dan ilk paketini 
geçirmiş birinden depolar arası merge'ü sorunsuz yapabilmesini beklemek 
mi onlar için daha korkutucu yoksa bir mail atmak mı siz düşünün.

Ha merge yükü 2 kişiye biniyor o yüzden yıkalım bu duvarları diyorsan, o 
ekipe birileri daha eklenebilir belki, bilemem.. Ama bence bu süreçte en 
iyi işleyen taraflardan biri Merge süreci.
> 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.
>   
+1.
> 3) Her bileşenin sorumlusu, derleme çiftliğinde kendi bileşeninin
> paketlerini derletir[1] (ve test deposuna aktarılmasını sağlamış olur).
>   
Bunun getirilerini aşağılarda tartıştınız ancak bana çok gerekli gibi 
gelmedi.
> 4) Güvenlik deposunun paketlerinin derlenmesi ve depoya aktarılması
> güvenlik depo sorumlusu tarafından yapılır.
>   
Güvenlik deposuna dair fikirlerimi belirttim yukarıda.
> 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.
>   
Güvenlik güncellemelerinin, ister senin 2'li depo düzeneğinde, ister şu 
anki tek kararlı depo düzeneğinde test edilmesinde ben bir fayda 
görmüyorum. Güvenlik güncellemesi bir yazılıma yeni özellik katmıyor adı 
üstünde, neyini test ediyoruz? Buffer overflow var diyor örneğin 
advisory'de, oturup gerçekten overflow var mı ve açığı kapatmış diye mi 
kontrol edeceğiz?

Güvenlik güncellemesi ortaya çıktığı anda yapılması gereken şey şu olmalı:
1. Yamayı pakete dahil et, derle, uygulamayı çalıştır, şöyle bir göz at,
2. Merge isteği yap, security olarak işaretlemeyi unutma,
3. Hemen merge edil, tek paket bile olsa, farm'a derlet ve gece 3 
rsync'ini beklemeden depoya yansıt.

Tabi ki bu plan esnetilebilir örneğin rsync noktasında  ya da geleceğini 
bildiğimiz bir diğer güncelleme bir süre beklenilebilir. Ben en sert 
planı yazdım.

Ha diyelim ki, öyle bir güvenlik güncellemesi yaptılar ki, açığı 
düzeltirken, başka bir yerde yeni bir açık ortaya çıkardı ya da daha da 
az olasılıkla olsa da yazılımın bir işlevini kırdı. Kusura bakmayın bu 
noktada da, "bu güncelleme programı kırdı, almayalım" deme şansımız 
olduğunu düşünmüyorum, o güncelleme yansıtılır, upstream durumu zaten 
farkedince yeni güvenlik güncellemesi yayınlar, o da alınır..
> 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].
>   
Bu aşağıda, 2'de dediğin bir şekilde soruna yol açmamalı. Ben 
hatırlamıyorum örneğini, (belki firefox sorunundaki glib 
güncellemesinden bahsediyor olabilirsin, ama orada sorun çok daha dallı 
budaklı bir şeydi).

system.base güncellemelerinde zaten daha yavaş ve tutarlıyız, 
gerekmedikçe güncelleme çok fazla yapılmıyor.
> 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.
>   
Anlamadığım 7 gün test deposunda bekledikten sonra bir de test takımı 
aracılığıyla test sürecine mi alınacak? Eğer evetse neden?

Bu test konusunda şunu düşünüyorum. Baştan beri test deposu hep şu 
şekilde kullanıldı:
- Bump et, merge iste, testte dursun.

Böyle bir düşünce yanlış diye düşünüyorum. Orası da insanlara sunulan 
ikili bir depo. Adı da kararsız değil, test. Önce paketçisi bir süre 
test etmeden, kullanmadan, "test deposuna girsin de orada millet 
kullanıp sorunu varsa söyler nasıl olsa" diye düşünmemeli. Paket 
devel'deyken kuran kullanan paket sahibi/bileşen sorumlusu bir sorun 
yakalayamazsa, test deposu daha ince sorunların yakalanabileceği bir üst 
katman olmalı.

Paketlerin burada bir X gün geçirip sonra bir de Y gün test sürecinde 
geçirip üzerine Z gün sonraki toplu güncellemeyle kararlı depoya 
girmesini yavaş bir süreç olarak görüyorum.

Geliştiricilerin daha dikkatli olmalı:
- Diğer dağıtımlara bakmalı, yeni sürüm başka bir yazılımın yeni bir 
sürümünü özellikle istiyor mu?,
- Yamalar neler? Bu yamayı almalı mıyım, işe yarar gibi mi duruyor, 
yoksa anlamsız mı?
- Bu kütüphanenin yeni sürümü, ona bağlı olan diğer yazılımları kırar mı?

Paketçisinin merge isteyip sallamadığı bu sorunları, Serbülent 
revdep-rebuild yapınca yakalıyor. Böyle olmamalı.
> 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).
>
> 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.
>   
Test ile ilgili fikirlerim yukarıda.

Benim süreç içinde en rahatsız olduğum şey, depoda N aydır çalışmaz bir 
şekilde duran bir paket hakkında hata girilip de "bu paket çalışmıyor" 
denildiğinde, düzeltilen paketin testte vakit geçirmesi. Paket zaten 
çalışmıyor, kesinlikle test edilmesine gerek yok ve test edilmesinde 
fayda yok, merge istediğim anda depoya alınması en akıllıcası.

Ya da mesela geçen gün firefox'a son anda ufak bir düzeltme girdi, 
kesinlikle zararsız ve kozmetik bir şey. Bu tarz şeylerin de test 
deposunda beklemesindense paketçisinin taahhüdünde doğrudan merge 
edilmesi(ya da hadi 1-2 gün testte dursun diyelim) daha doğru olur.

Artık urgency=(low, medium, high, bugfix) tarzı bir şey mi yazıp bunu 
belli ederiz merge mailinde, başka bir şey mi bilemiyorum.

Selamlar,

-- 
Ozan Çağlayan