[Gelistirici] Kırık firefox 3.0.3 paketi

[Onur Küçük]

On Sun, 5 Oct 2008 06:58:40 +0300
Erkan Tekman <tekman at pardus.org.tr> wrote:
...
> Burada da şu konuları konuşmak yerinde olacaktır sanırım:
> 
> * Güncel olmak/kalmak ile kararlı olmak/kalmak arasında seçimi hep
> ilkinden yana yapıyoruz. Bu durum gözden geçirilmeli mi?

 Bu tarz sorunların en az yaşandığı bir tek Slackware
aklıma geliyor. Sebebi bir sürü, ama özetle "son kullanıcı için dağıtım
geliştirmemek" ve "bir tane ne yaptığını çok çok iyi bilen deli
tarafından dar bir çerçevede geliştiriliyor olmak", ve bunlar ne bize ne
SuSe'ye ne Fedora'ya uymuyor. 

 Güncel olmak demek kararlı olmamak demek değildir. Kararlı olmak için;

 - herşeyden önce önce ne yaptığını bilmek gerekir
 - yaptığın işte dikkatli olmak titiz olmak 
 - yaptığın işi düzgün test etmek
 - tamam dediğin noktada test ekibine sunmak, böylece kaçırdığın
görmediğin, kendi değişikliklerin ya da deponun geri kalanı ile uyum
ile ilgili sorunların farklı gözler / farklı bakış açısı / farklı
kullanım şekilleri ile incelenmesini sağlamak

 gerekiyor. Bu kadar adımla da sadece "daha kararlı" bir sonuç
elde edilebilir, mükemmeli elde edemezsiniz, mutlaka arada birşeyler
gözden kaçablir. Ha ne yapılır, otomatik araçlarla linker üzerinden
kitaplıkların dosya isimlerine bakılır, yetmedi sembollere bakılır,
yetmedi dlopen larda değişiklik var mı bakılır, yetmedi makrolarda
değişiklik var mı diye bakılır, derken liste uzar gider.

 Amaç "mükemmel" ise o zaman yapılan bütün değişikliklerin
inanılmaz derecede dikkatli, ne yaptığını bilen robotlar tarafından
"satır satır" okunması ve incelenmesi gerekiyor. Bunu tam yapabilen
dağıtım benim bildiğim yok, diğer dağıtımlar bize kıyasla
büyük işgüçleri ve ana geliştirme sürecinin içinde bir sürü
adamları olması (upstream geliştiricilerinin kendi adamları
olması) sayesinde buna bayağı yaklaşıyorlar, ama mükemmel olabileceğine
de pek ihtimal vermiyorum.

 Güncelleme yapmamak demek de bir sürü hata düzeltmesi / iyileştirmeden
mahrum kalmak, çok hızlı gelişen açık kod dünyasında geri kalmak demek.
Bu sadece bizim hata kayıt sistemimizle sınırlı sorunları kapsamıyor.
Bir video dosyasını oynatamamak / yarı performansta oynatmak, Internet
üzerinden iletişim sistemlerine bağlanamamak, sürümü eski kaldı diye
bir oyunla Internet sunucularına girememek "kararlı kalmak adına" o
yazılımları tamamen işlevsiz kılabilir, ki bu benim aklıma hiç yatmıyor.


> * Test süreçleri sürekli olarak yavaşlatıcı bir etken olarak
> görülüyor. Böyle olması kötü mü? Ve/veya daha hızlı olması mümkün mü?

 Doruk'un söylediklerine genelde katılıyorum. Ama sorunu en başından en
sonuna, yani sonucun kullanıcıya ulaşmasına kadar, bütün süreçleri
birleştirerek toplamda ne kadar hızlı olduğumuza bakarak incelemeliyiz.

 Örneğin bilgisayarınızda bir sorun var ve tamirciye götürdünüz. Bir kaç
gün sonra tamirci size "sorunu buldum, düzelttim, deniyorum" dedi ve
sesi kesildi. Belki arada "eee ne oldu bizim bilgisayar" dediniz,
aldığınız cevap da hep "düzelttim yolladım, yakında elinizde olur"
oldu. Bu duruma ne kadar sabredebilirsiniz ? Tıkanma noktası test
süreci mi gerçekten bilmiyorum ama 2008 için geliştirici listesinde en
son ACK/NACK 1 ay önce sorulmuş, daha yeni seri için bir şey
kaçırmadıysam ACK/NACK yok. Tamirciden 1 ay ses çıkmazsa ne
düşünürsünüz ?

 Sorun uzun süren testler mi, yoksa test etmeye başlamak için o kadar
süre mi bekliyoruz ? (Sürecin dışındayım, bilmiyorum) Test sistemi ile
ilgili sorunlar var ama bir problem yakalanmadı diye bütün suç test
sürecinde mi ?

 Ben başka bir soru sorayım. Bu tarz acil sıkıntılarda ne kadar hızlı
müdahale edebiliyoruz ?

 Kendi içimizde "one man single point of failure" lar (düzgün bir
karşılık aklıma gelmedi) olduğu sürece (hiç kimse 7/24 hizmet verebilen
robot değil) o ya da bu şekilde böyle tıkanmalarımız hep olacak, sorunu
ve hatta çözümü biliyor olsak bile elimiz kolumuz bağlı bekleyeceğiz.

-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens