[Gelistirici] Kurumsal2 Depo Politikası (was Re: MySQL 5.5)

[Serdar Dalgıç]

13 Ocak 2011 Perşembe günü (saat 23:23:49) Ekin Meroğlu şunları yazmıştı:
> 
> <sildim>
>
> ... Test
> edilmesi için gerekli süreçleri yaratmadan, önlemleri almadan ne kadar
> evet dersek diyelim bu tip bir güncellemeyi depoya almayalım.
> 

ya da alacağımız depo "stable" depo olmasın. 

Depo ayrımının gerekliliğine ben de katılıyorum. Düşündüklerimi yazıya dökeyim 
dedim, biraz uzun oldu ama analitik oldu, gözünüzü korkutmasın ;) 

Erdem'in dediği gibi, "hemen, şimdi" olmasa da en kısa zamanda devel / stable 
ayrımını yapalım. Devel'i stable'a kopyalayıp başlatalım süreci.

* Stable kararlı tutulur.

* devel'deki paketlerin stable'a aktarılması Bugzilla üzerinden hata açılarak 
sağlanır.  Paketin kararlı olduğunu iddia etmek için belirli çıktılara 
bakabiliriz. İlk aklıma gelenler şunlar: 

Desteklediğimiz iki mimariyi de göz önünde bulundurarak.
- revdep-rebuild çıktısı
- checkelf çıktısı
- varsa paketin içinden çıkan testlerin çalıştırılması.
- varsa paketçinin yazdığı/kullandığı testler.
- test takımının paketin testi için yazdığı belgelerdeki testler.
- paketin üzerindeki hatalar, paket test edilirken karşılaşılan hatalar.

Stable'a paketin aktarılması için gözden geçirme yapacaklar da 

1 - paketin bileşeninin sorumlusu ya da üst bileşen sorumlularından biri (bu 
paketçinin kendisi de olabilir)

2 - Paketi test eden diğer geliştiriciler (en az bir, ama ne kadar çok 
kararlılığı onaylayan yorum gelirse güzel olur)

3 - Test Ekibinden bir kişi (ideal dünyada bu ŞART olmalı, ama Semen tek 
başına bütün stable'a alınacak paketlerin testlerine yetişemeyeceği için 
(Semen'den başka da test ekibi üyesi yok bildiğim kadarıyla) OPSİYONEL 
diyebiliriz)

4 - Bu verileri gözden geçirip paketin alınmasına OK verecek olan sürüm 
yönetici(si/lerinden biri)

Bu noktada test işini önemsemediğim zannedilmesin, tam tersine paketçilerin 
`self package testing` pratiklerini arttırmak, başta Semen olmak üzere testle 
ilgilenen arkadaşların üzerindeki yükü bir nebze hafifletmek amacıyla bunları 
yazdım.

Ayrıca bu yöntemle paket know-how'ının paylaşılması da sağlanacak. 
Geliştiriciler bakımını üstlenmedikleri paketlerdeki değişiklikler hakkında 
daha çok bilgi sahibi olacaklar. 

******
Peki devel/stable ayrımı hem kaynak, hem ikili depolarda mı olacak? Yoksa 
sadece ikili depolarda mı olacak? Her iki seçenek de aşağıda:
******

AYRI KAYNAK DEPO:
---------------------------
İki mimari iki farklı depo, 4 buildfarm demek, bu da çok fazla iş gücü 
anlamına geliyor, fiziksel imkanların da olgunlaşması lazım. (Bildiğim 
kadarıyla "hemen yarın 4 buildfarm'ı ayağa kaldırıyoruz" durumunda değiliz) 
Avantajları:

1 -) Her iki deponun farklı distribution.xml'leri olacak, obsolete paketler 
açısından herhangi bir karışıklık olmayacak. 
(Sorunlu durum örneği: X paketini replace eden Y paketi stable'a girmedi, ama 
devel'de. Tek kaynak olsaydı distribution.xml'de X obsolete işaretlenirse Y 
devel'den stable'a geçene kadar stable'da X paketi olamayacak. Workaround: 
Replaces'ları obsolete işaretlemeyiz, o zaman da dist-upgrade'lerde başımızı 
ağrıyor.)

2 -) Stable'da bir pakete güvenlik güncellemesi geldi diyelim. O güvenlik 
sadece stable'da yapılabilecek, devel'deki yeterli miktarda test edilmemiş bir 
paketi stable'a almaya gerek kalmayabilecek. 

Örnek senaryo: X paketi version 1.0.0 stable depoda olsun. Devel'deki sürümü 
de 1.1.0. X paketinin 1.0.0 sürümünü etkileyen bir güvenlik açığının 
güncellemesi sadece stable'a uygulanabilecek. 
Pardus 2009'dayken devel'deki 1.1.0 paketinin üzerine yamayı ekleyip 1.1.0 
paketini de stable'a almak zorunda kalıyorduk.

TEK KAYNAK DEPO:
---------------------------
Bakımı daha kolay, 

* Devel ikili deposundan stable ikili deposuna paketler kopyalanacak, 
pardus-2009-test -> pardus-2009 'da olduğu gibi.

1 -) İkili depoların index'i çıkartılırken ayrı distribution.xml'ler kullanmak 
zorunda olacağız. Pardus 2009'daki gibi "not gone to binary stable yet, please 
don't remove this mark" gibi bir işaretçi kullanıp stable'da ve devel'de 
kullanılacak distribution.xml'leri çok dikkatli oluşturmamız lazım. (sürüm 
yöneticileri için PITR.)

2 -) Güvenlik güncellemesi sorunsalı, üstte anlattığım senaryodan muzdârip 
olacağız. "Test takımına güvenimiz tam" :) diyip Pardus 2009'daki davranışı 
sürdürür müyüz, bilmiyorum.
---------------------------
Aklıma gelenleri özetlemeye çalıştım. Atladığım eksik bir şeyler ya da yanlış 
yorumladığım bir kısım varsa; eklemek istediğiniz, yorumunuz, önerileriniz 
varsa buyrun.

Bu tarz sınırlar çizmediğimiz sürece "..Test edilmesi için gerekli süreçleri 
yaratmadan, önlemleri almadan.." gibi cümlelerimiz hep havada kalacaktır.

-- 
- Serdar Dalgic
TUBITAK/UEKAE - Pardus GNU/Linux
http://www.pardus.org.tr/eng