[Gelistirici] kararli depoya paket gecis sureci

[Onur Küçük]

On Thu, 4 Dec 2008 18:05:33 +0200
Doruk Fisek <dfisek at fisek.com.tr> wrote:
...
> 1) Bakıcısız tüm paketler işaretlenir.
> 2) Her bilesen icin birer bilesen sorumlusu secilir.

 Bu ikisini ben "olmazsa olmaz" olarak görüyorum. Sınırlar ve
sorumluluklar artık biraz daha netleşmeli.

 Şu anda paketler kimin hangi paketiyle ne kadar ilgilenebildiğini
bilmediğimiz için anarşik bir yaklaşımla güncelleniyor / hataları
düzeltiliyor. "Bir şekilde yürüyor" da kabul edilebilir bir yaklaşım
değil, çünkü şu anki haliyle ciddi bir odaklanma sorunu ve "haksızlık
derecesinde" iş yükü dağılımı yüzünden kalite düşüklüğüne sebep oluyor.

 Bu sebeplerden, ortaya koyduğum işin kalitesinin düşmeye başladığını
görüyorum ve bundan çok ciddi rahatsızlık duyuyorum.

> 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.

 Böyle bir deponun olması bana mantıklı gelmiyor. Hem bir "security
only" depo, hem de "update / non critical bugfix / feature / security"
depo bir arada yaşatmak demek neredeyse iki ayrı dağıtım sürdürmek
demek. Burada güvenlik düzeltmelerinde yazılımın elinizdeki sürüme
"yeni sürümü üzerine eklenen düzeltmeyi" backport etmek bazen çok kanlı
olabiliyor.

 Zaten gücümüz ortada, bu tarz bir çift dikiş yapıya yöneleceksek daha
çok işe yarayacak / daha çok ilgi çekecek / daha çok fark yaratacak bir
alanda (mesela 64bit sürümü ile) yönelmek mantıklı olabilir.


> 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.

 Evet bu hayata geçmeli, X paket grubuna bir kaç adım uzaktan bakabilen
insanlar gerekiyor

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

 Pardus farmlarının şu anki yapısı sebebiyle aynı anda 5-10 kişi
tarafından yönetilebilmesi mümkün gelmiyor bana. Birden fazla kişi
belki olabilir, ama bu kişilerin iyi bir uyum içerisinde çalışabilmesi
gerekiyor.

> 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].

 Tek tek her olasılığı test etmek o kadar da aklıma yatmıyor.
Çıkabilecek sorunlar, paketlerin bağımlılıkları vb. adını
koyabildiğimiz / belli çerçevelerde tanımlayabildiğimiz pek çok şeyin
takibini daha da otomatikleştirebilmeliyiz. Belki bunun için şu ana
kadar gelen bazı alışkanlıklarımızı da değştirmemiz yerinde olabilir.
Pardus'un artı yönleri, eskiden kalma yanlışları sırtından atmaya karar
verdiğinde bunu (her zaman olmasa da genelde) becerebiliyor olmasından
kaynaklanıyor, belki kendi gelişim sürecimizde de bazı kamburları atmak
akıllıca olabilir.

> 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).

 Bundan çok emin değilim. Bir paketin test sürecine girmesi şu anda
malesef ancak pakette güncelleme olduğunda oluyor. Şu anda depodaki
paketlerde hangi hataların olduğu, test ekibinin yakaladığı sorunun
güncelleme ile mi geldiği yoksa zaten daha önceki pakette de mi
olduğunu bilmiyoruz. Doğru tabiri ile "regression" var ise güncellemeyi
yapan kişiye, "regression" değil ise hata kaydı paketin sahibine "test
sürecinin bitmesi beklenmeden" atanmalı ki ilgili geliştirici bir an
önce sorundan haberdar olup çözümü için uğraşmaya başlayabilsin.


-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens