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 _______________________________________________ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici