[Gelistirici] Kurumsal 2 depoları

[Ozan Çağlayan]

On 04.03.2011 01:30, Necdet Yücel wrote:
> Selamlar,

> Kurumsal 2 depo politikası hakkında bir gelişme var mı acaba?

İki toplantı yaptık bu konuyla ilgili. Biraz mesafe katettik, halen
kararlaştıramadığımız noktalar var. Şu anda notlarım önümde değil ancak
özet geçebilirim:

* Ana depodaki paketlerin pspec.xml dosyasında yazan bakıcıları Tübitak
çalışanları olacak,

* devel kaynak deposu commit'lere açık. Ancak devel->testing geçişi
esnasında bir e-posta listesi üzerinden (eski stable at pardus.org.tr gibi)
onay alınacak. Eskisi kadar zahmetli olmasın diye bu onay mekanizması
bir betik ile yapılabilir diye konuştuk. Yani listeye otomatik e-posta
atan, e-posta'ya pakette yapılan değişikliği diff olarak bilgi amaçlı
ekleyen, bugzilla'da çözdüğü hata varsa o bilgiyi geliştiriciden isteyen
ve listeye mesela:

****

[SECURITY] Merge request for mit-kerberos (#17777)

The user ozan.caglayan (Ozan Çağlayan) has requested a merge request for
the mit-kerberos package.

This update will resolve the bug "Fix several security vulnerabilities"
(#17777) on bugs.pardus.org.tr.

Attached is a unified diff reflecting the changes done to the package.

****

gibi bir e-posta düşecek. Bir *ekip* tarafından bu istekler onaylanacak
veya reddedilecek.

* Security veya Critical olarak işaretlenmemiş güncellemeler, testing
deposundan kararlı depoya geçemeyecek. (Örneğin, kozmetik, çeviri,
desktop dosyası düzeltmesi veya sistem için *gerçekten* kritikliği
bulunmayan güncellemeler). Bu güncellemeler bir sonraki ara C2 sürümü
için testing'de bekler durumda olacak. Böylece kullanıcı gerçekten
kritik olmayan bu tarz değişiklikleri sürekli güncelleme olarak almayacak.

* Kritiklik ataması geliştirici tarafından gerçekleştirilecek olsa da
ekip listede kritik olarak işaretlenmiş bir güncellemenin kritik
olmadığına veya tersine karar verebilecek. Çünkü kritikliğin tanımını
yapmak gerçekten zor.

* devel kaynak deposu ileride testing'e alınması yüksek ihtimal olan
güncellemeleri içerecek ancak asla playground'a dönüşmeyecek. Yani devel
deposunda çekirdek paketine sadece test edilsin diye köklü değişiklik
yapılmayacak veya mit-kerberos paketi majör sürüm atlamayacak. Yani
devel deposu ileri gidebilecek ancak makas asla açılmayacak.

* Güvenlik güncellemeleri sadece güvenlik güncellemeleri olacak.
Güvenlik güncellemeleri olabildiğince yama olarak yapılacak. *Sadece*
güvenlik güncellemesini içeren bir sürüm arttırma var ise upstream
tarafından yapılan o sürüme geçilebilecek. Ancak ortada gezinen yamalar
backport edilemiyorsa, edilmesi riskliyse, ve güvenlik güncellemesi
upstream'in çıkarttığı yeni sürümde içeriliyor ancak başka değişiklikler
de varsa, listeden onay almak koşuluyla yeni sürüme geçilecek.

* Güncellemeler atomik olacak. Yani güvenlik güncellemesiyle beraber,
desktop dosyasına TR çeviri veya çıkmayan simge hatasının düzeltilmesi
gibi başka bir değişiklik girmeyecek. Bir güncelleme, Bir release
arttırımına denk düşecek. Bir devel->testing merge'ü esnasında diff
çıktısında 1'den fazla release arttırımı görülmeyecek.

* Hiçbir şekilde sürüm içinde kitaplıklar, ters bağımlılıklarının da
güncellenmesine gerek duyulacak şekilde güncellenmeyecek.

Kalan konular
-------------

* Testing deposuna giren paketler ne kadar süre sonra kararlı depoya
yansıyacak? Güvenlik güncellemeleri, kritik güncellemeler ve diğer
güncellemeler için bu süreler farklılık gösterecek mi? (Güvenlik
güncellemeleri çok daha hızlı girecek bu kesin ama kural ne olacak, test
nasıl yapılacak?)

* Onay mekanizmasının gerçeklenmesi,

* Onay ekibinin belirlenmesi,


Unuttuğum noktalar vardır mutlaka. Pazartesi günü tamamlamaya çalışırım.



-- 
Pardus Linux
http://www.pardus.org.tr/eng