[Gelistirici] mit-kerberos paketi check hatası

[Erdem Bayer]

Selamlar

On Paz, 2011-01-02 at 15:33 +0200, Fethican Coşkuner wrote:
>    Testi hiç bir zaman doğru çalışmayan bir pakete yazmanın bir
> manası olmayabilir belki ancak patlamadan çalışanlar için kullanışlı
> olabiliyor güncellemelerden sonra kontrol etmek açısından. Zaten
> pakete
> check eklemek paket sahibinin inisiyatifinde olan bir şey. 

Sanırım yazılan testler sadece o paket güncellendiğinde paketin düzgün
çalışıp çalışmayacağını değil, depodaki herhangi bir değişiklik
sonucunda paketin düzgün çalışıp çalışmayacağını test etmek içindir.
Eğer paketlerin inşa aşamasında farm'a tüm paketler için paket sahibinin
yazdığı testleri yoksay diyor isek (benim anladığım şu an durum böyle)
hem paket inşa sistemimizin (örn: buildfarm) hem de paket yönetim
sistemimizin (örn: check foksiyonu) amaçlarını ve çalışma prensiplerini
yeniden düşünme vaktimiz gelmiş demektir.

Birkaç örnek vereyim: (arada yanlış bildiklerim olabilir, eğer öyle ise
lütfen düzeltin.)

* Şu anki paket inşa sistemimiz runtime bağımlılıkları çözebilmek için
bütün paketleri inşa ettiği alana kuruyor, dolayısı ile bir paketin
bağımlılıkları doğru yazılmamışsa farm'ın bunu yakalama ve uyarma şansı
olmuyor.

* A paketinde bir değişiklik olmuş ise, A paketinin tüm ters
bağımlılıklarının bu değişiklikten etkilenip etkilenmedikleri test
edilmiyor. Bu testi yapmasını sınırlı kaynağı ve zamanı olan paket
sahibinden bekliyoruz.

* Paketçiden bir pakette yapılan ufak bir değişikliği bile 3 farklı
dağıtım ve iki mimari üzerinde kendi başına inşa ve test etmesini
bekliyoruz. (Yine sınırlı kaynak ve zaman problemi)

* Paket yönetim sistemimizin bir paketi güncellemekten anladığı şey
paketin eski sürümünü kaldırıp yeni sürümünü kurmak. Bu durum paketin
güncellenme aşamasında yapılması gereken özel birşey varsa elimizi
kolumuzu bağlıyor.

* Paket yönetim sistemimiz içinden servis betiği çıkan paketleri servis
ile ilgili herhangi bir işlem yapmadan kaldırıyor, daha sonra yeniden
kurmaya çalıştığında (örn: güncelleme) karşılaşılan bir hata sistemi
geri dönülmez durumda bırakabiliyor. Örn: Paket kaldırıldı, ancak servis
durmadığı için yeniden kurulamıyor, artık paket de gittiği için servisi
durdurmanın herhangi bir yolu da yoksa ne yapacağımızı şaşırabiliyoruz.
(Teorik bir örnek değil, geçen gün eski bir makine üzerinde nfs-server
paketini güncellerken başıma geldi.)

* Paketlerimizin farklı mimarilerde farklı ihtiyaçları var ise (örn:
farklı bağımlılıklar) bu ihtiyaçları karşılayamıyoruz veya karşılamakta
zorlanabiliyoruz.

On Paz, 2011-01-02 at 15:43 +0200, Ozan Çağlayan wrote:
> Paketçi, paketin test içerip içermediğini bilmeli, içeriyorsa bunu 
>actions.py'ye ekleyip, paketinin bakımını yaparken testleri çalıştırıp 
> sorunları tespti edip çözülemesi gerekli olanları çözmelidir. Bazı 
> paketlerin testleri 4-5 saat sürebiliyor, farmda testleri yaptırmak 
> makul bir şey değil.
 
Bazı testler 4-5 saat sürebiliyorsa bu testlerin yapılmasının yeri bence
elle yapılan bir inşa yerine tam da otomatik çalışan bir sistem olan
farm olmalıdır. Uzun süren işlemi otomatik çalışan uygulamaya değil de
elle çalıştırılan ve kişisel çalışma ortamlarımızın kaynağını harcayan
bir yönteme bırakmak sadece bana mı mantıksız geliyor?

4-5 saat süren bir testi paketçiye bırakmak demek o paketçinin yaptığı
en küçük bir değişiklik için bile 5*6=30 saatini ve bu 30 saat boyunca
sahip olduğu kaynakları harcaması demek. (O da sadece testin başarı ile
sonuçlandığı durumda!)

Ayrıca yukarıda yazdığın cümle her ne kadar doğru gözükse de yazılan
testlerin sadece o paketle ilgili olmadığı, paketin bağımlı olduğu diğer
tüm uygulamalar ile o paket arasındaki ilişkiyi de kontrol ettiğini
düşündüğümüzde testlerin sadece o paket üzerinde bir değişiklik
yapıldığında değil bağımlılıkları içinde bir değişiklik olduğunda da
çalıştırılması gerekliliği ortaya çıkıyor, bunu da paketçiye bırakmanın
insafsızlık olduğunu düşünüyorum.

Ayrıca testler dışında inşası uzun süren paketler de var, yine bu
paketlerde yapılan en ufak değişikliği de 6 ayrı yerde inşa ederek test
etmesini paketçiden bekliyoruz, halbuki bunu otomatik yapabilen bir
yazılım var ise bu da bana insafsızlık gibi geliyor.

İşte tam da bu sebeplerden dolayı daha fazla ilerleyip iyice geri
dönülemez noktaya gelmeden hem paket inşa sistemimiz hem de paket
yönetim sistemimiz ile ilgili gereksinimlerimizi yeniden konuşmamız ve
buna göre bir yol haritası çıkarmamız gerektiğini düşünüyorum.

İtiraz eden yoksa bu işin sekreteryasını üstlenip bir karara
varabilmemiz için gerekli ayarlamaları yapabilirim.

Saygılarımla
Erdem Bayer