[Gelistirici] kararli depoya paket gecis sureci

[Ekin Meroğlu]

Merhaba;

Friday 05 December 2008 tarihinde, Ozan Çağlayan şunları yazmıştı: 
> Doruk Fisek wrote On 04-12-2008 18:05:
> 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?

http://liste.pardus.org.tr/gelistirici/2008-December/015127.html

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

+1

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

Bu itirazın adı geçen güncellemenin __sadece__ güvenlik güncellemesi içerdiği 
durumlar için geçerli ama - kernelden kütüphanelere kadar bir sürü yazılım 
kendi sürüm takvimleri ile çakışan güvenlik fixlerini normalde 
yayınlayacakları yeni sürümlerine ekleyip yayınlıyor - on yeni özellik, iki 
bugfix, bir security içeren bir güncelleme tanım gereği security ama test 
edilmemesi gibi ihtimal yok maalesef.

Senin senaryo ancak sıkı kararlı depo politikası ile, sürüm atlatmadan sadece 
sec. fixleri backport edersek uygulanabiliyor. Security ekibimiz sağolsun 
olabildiğince backportlar ile bu güncellemelerin hızla depoya girmesini 
sağlıyor, ama her zaman uygulanabilir değil.
 
> > 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].

> system.base güncellemelerinde zaten daha yavaş ve tutarlıyız,
> gerekmedikçe güncelleme çok fazla yapılmıyor.

Burada da daha sıkı bir politika uygulamalıyız aslında.

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

Evet geliştirici en azından bir süre kullanmalı, temel fonksiyonlarının 
çalıştığından emin olmalı paket test deposuna alınmadan önce, ama örneğin 
Amarok 2 beta1'in test deposuna girip daha geniş bir geliştirici ekibi 
tarafından test edilmesinde büyük bir sorun yok bence.
   
> Paketçisinin merge isteyip sallamadığı bu sorunları, Serbülent
> revdep-rebuild yapınca yakalıyor. Böyle olmamalı.

Evet paketçiler daha ilgili olmalı, belki sık rastlanan sorunlar ve test 
yöntemleri gibi bir geliştirici belgesi yararlı olur. Ama depo kararlılığı 
konusunda mutlaka gözden kaçacak bir seri hata olacaktır, depo bütünlüğünü 
daha otomatik araçlarla daha sıkı kontrol etmeliyiz.

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

Bunu merge'de nasıl security işaretlediğimizde direk depoya alıyorsam kritik 
olarak belirtirsen hemen depoya alırız aslında - sorun genelde bu durumu 
ACK/NACK'ta konuşmamızda bence.
 
> 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.

Evet, trivial düzeltmeler için de bir exception olmalı politikada - bunlar 
testçilerin de işini azaltacak önlemler aslında.

--
İyi Çalışmalar;
Ekin Meroglu <ekin_at_pardus.org.tr>

... did i listen to pop music because i was miserable, or was i miserable
because i listened to pop music?... - rob [nick hornby / hi fi]