[Gelistirici] [Stable] [2008] programming/libs/neon

[Ekin Meroğlu]

İnanç bey,

Sunday 10 August 2008 tarihinde, İnanç Yıldırgan şunları yazmıştı: 
> Version bump.

Bu sürüm yükseltme işlemi,  /usr/lib/libneon.so.26 --> /usr/lib/libneon.so.27 
geçişi getiriyor, neon paketinin ters bağımlılıkları olan openoffice ve 
subversion paketlerini (en azından) kırıyor.

Pardus 2008 sürümü çıktığından beri 2008 deposuna commit hakkının kısıtlanıp 
her güncellemenin kararlı depoya girmemesinin sebebi, benim merge işini 
anlamsız derecede çok sevmem değil maalesef - kararlı bir ürünün (Pardus 
2008) kararlılığını bozabilecek hamlelerden kaçınma, bir sonraki sürüme giden 
geliştirme faaliyetleri ile kararlı sürümü ayırma zorunluluğumuz. 

Kararlı depomuzun bir güncelleme politikası var [1] ve ilk birkaç kuralı 
şöyle : 

> #  Kararlı depo bir platformdur, desteklediği belli bir donanım seti, belli
> bir özellik kümesi vardır, Bu kümeyi sürekli arttırmaya çalışmak platformun
> kararlığını ve bütünlüğü bozar. Her yeniliği, her güncellemeyi bu platforma
> eklemeye çalışmak yeni bir dağıtım sürümünün çıkması demektir bu sebeple
> çok gerekli olmadığı durumlarda kararlı depoda güncelleme yapmak yasaktır.
> # Kararlı depoda ABI bozmak kesinlikle yasaktır,
> # Kararlı depoda API sadece kontrollü şekilde bozulabilir, API'nin
> bozulması gereken durumlarda API'yi bozmak isteyen geliştirici paketi
> depoya göndermeden önce neden bunun gerekli olduğu geliştirici e-posta
> listesine anlatmalı ve sürüm yöneticisinden onay beklemelidir.
 
Evet, dağıtım olarak güncel kalalım - eskimiş bir dağıtımı ne kullanıcılar ne 
de geliştiriciler sever. Ama bunu yaparken her güncellemeyi kararlı depoya 
almak doğru yöntem değil.

Kaldı ki bir kütüphaneyi güncelleyen bir geliştiricinin, kütüphaneyi kendi 
sisteminde - en azından ters bağımlılıklar açısından - bir testten geçirmesi, 
paketteki değişikliklerden haberdar olması, sürüm takip ekibini bu konuda 
bilgilendirmesi gerekir - Merge isteği yapan bir geliştiricinin kendi 
sisteminde bir en azından bir revdep-rebuild çalıştırmış olduğundan emin 
olmalıyız - bunu bekleyebilmeliyiz. Yoksa paket güncellemek bir betik ile 
hızla yapılabilecek pspec.xml/actions.py değişikliğine gidiyor.

Özetle, depoda eski kalmış her paketi acele güncellemek yerine belli bir paket 
kümesini seçip, bu paketlerin geliştiriciliğini üzerinize alarak tüm 
sorunları ve yapılarıyla uğraşmanız, sonrasında ise artan tecrübenizle 
birlikte zamanla daha fazla paketle uğraşmaya başlamanız daha doğru bir yol 
gibi görünüyor.  

Bu yazdıklarımın size denk gelmesi, sadece sizin için geçerli anlamına 
gelmiyor tabii ki : Sizin ve tüm liste sakinlerinin bu iletiyi öncelikle 
kararlı depo politikası ile ilgili bir uyarı, sonrasında da yeni 
geliştiricilere genel bir tavsiye olarak yorumlayacaklarını umuyorum.

[1]
http://tr.pardus-wiki.org/Pardus:Depo_Politikası   
--
İ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]