[Gelistirici] Contrib Depo Farkları ve Deponun Durumu

[Ekin Meroğlu]

Merhaba;

Bu tartışma çıktığında yıllık iznimin bir kısmını kullanıyor olduğumdan cevap 
yazamadım - adım da geçmiş üstelik :-)

Tartışmayı tekrar alevlendirmek gibi bir niyetim yok - konunun teknik olmayan 
yanlarına dair cevapları acımadan pardus-polemik listesine yönlendireceğim. 
Ama yanlış anlaşılmalar birbirini kovalıyor - merak edenler için depo/ 
paketler / farm konularında benim fikirlerim aşağıda..

Cumartesi 13 Eylül 2008 tarihinde, İnanç Yıldırgan şunları yazmıştı: 
> Contrib deposunda paketçileri tarafından merge edilmeyi bekleyen 476 paket
> var. 2008 sürümü çıkalı yaklaşık 3 ay oldu. Öyle ki bugün 2008.1 sürümü
> bile taglendi. Ama contrib deposu hızla çöplük olmaya doğru ilerliyor.
> Paketçileri çeşitli sebeplerden dolayı bu paketlerle ilgilenemiyor
> olmalılar diye düşünüyorum. Şu an aklıma gelen bir çözüm önerisi yok ama
> buna bir çözüm bulmalıyız. Tüm gelişticiler ile ele ele vererek bir şeyler
> yapılabilir belki. 

Bu konu hakkında gerekli yorumlar yapılmış aslında. 

Özetle bir geliştirici paketi ile ilgilenmiyorsa geliştirici olarak iki 
seçeneğimiz var :
- "ne yapalım, sorumluluğunu bilseydi" deyip görmezden gelebiliriz,
- "benim ilgilendiğim ve bilgi sahibi olduğum bir alan" deyip, paket 
geliştiricisinin onayı ile paketi üzerimize alabiliriz.
Bunun dışında benim bildiğim bir yol yok, geliştiriciye silah zoruyla bakım 
yaptıramayacağımıza göre.
Daha önce de yazdım, depo / sürüm yöneticilerinin ise bir seçeneği daha var, 
zorunlu olmadıkça kullanmadıkları :
- diğer paketlerin bağımlılıklarını veya depo tutarlılığını sağlamak için bazı 
paketlerin geçici bakımını yaparak çalışır / derlenir hale getirmek, kararlı 
depoya almak. 2008 öncesinde devel deposunda bakıcısız paket sayısı hayli 
fazla olduğundan bu seçeneği yoğun olarak kullandık, ama artık işleri 
normalleştirmek gerek.

Doruk'un dediği gibi bakıcısız paketleri işaretlemek için sürdürülebilir bir 
yöntem geliştirmek ilk anda çok yararlı olacaktır, daha sonra da 
paketlerin "gerçekten" bakıcı olan geliştiriciler tarafından maintain 
edilmesini yaygınlaştırmalıyız. Burada önemli olan, geliştiricilerin 
üzerlerine alacakları paketleri ilgili ve bilgili oldukları alanlardan 
seçmeleri - yoksa "bu paketler sahipsizmiş, aldım gitti" yöntemi ile avuç 
avuç paketi üzerine geçirip altı ay sonra şu veya bu nedenle projeden 
uzaklaşan geliştiriciler de gördü bu proje, ve maalesef çok yaygın bir hata 
bu.       

> Ayrıca şu an ki sorumlu Eren'in bu sene gireceği 
> sınavdan ötürü depoyla ilgilenmeye yeterli vakti olmayacağını düşündüğümden
> depo sorumlusunu yeniden tayin etmemiz de deponun 2008 sürmüne uyum
> sürecini hızlandıracaktır. 

Depo / farm sorumlusu maalesef "adayları belirleyelim, oyları alalım, evet sen 
oldun, hadi uğurlu olsun" yöntemiyle belirlenemiyor - projenin çoğu sürecinde 
olduğu gibi öncelik elini taşın altına sokma, birlikte çalışabilme, devamlı 
ulaşılabilir / fikir alışverişinde bulunulabilir olma özelliklerinde. 

Farm sorumlusu ikili paketleri son kullanıcıya ürün olarak sunan kişi 
olduğundan, bu aşamada çıkabilecek hatalar ve sorunlar doğrudan kullanıcıları 
etkiliyor. Diğer yandan, sorun çözümleri için doğrudan geliştiricilerle 
çalışması, acil durumlarda doğrudan müdahale edebilmesi de gerekiyor farm 
sorumlusunun. Contrib'de işler daha da karışık - herkes kontrolsüz bir 
şekilde merge ediyor paketleri, bu farm sorumlusunun devamlı  takipte 
olmasını gerektiriyor. Contrib'deki bir başka zorluk da bir ikili test 
deposunun olmaması - derlediğiniz her paket kullanıcılarınıza doğrudan 
sunuluyor.

Özetle, farm sorumluluğu oldukça düzenli zaman ayrılması gereken yoğun bir 
iş - öncesinde de bir önceki sorumludan biraz ders almak, iş yapış tarz ve 
yöntemlerini, proje içinde çalışma süreçlerimizi öğrenmek gerekiyor. 
Dolayısıyla yeni farm sorumlusunun eski sorumlu tarafından seçilmesi (en 
azından önerilmesi) bir anlamda gerekli - bu iş bilgi / yetenek olduğundan 
daha fazla sorumluluk.     

> Ayrıca bildiğim kadarıyla contrib deposu farmına 
> sadece depo yöneticisinin erişim hakkı var. Çekirdek ekip harici bazı
> geliştiricilerde farma erişim haklarının olduğunu söylüyorlar. Eğer böyle
> biri durum var ise erişim hakkının tüm geliştiricilere verilmesi gerekmez
> mi?

Hayır. Birden fazla kişinin farm'a erişiminin olması işleri karıştırmaktan 
başka birşeye yaramıyor - görece seyrek çalışan 2007 farmında bile Çağlar'la 
ben birbirimizin ayağına basmamak için fazladan önlemler alıyoruz, 2008 
farmlarında uygulanabilir olduğunu düşünmüyorum. Ama iki geliştirici "biz bir 
ekip olarak bu işi yaparız, yöntemimizi ona göre seçer, düzenleriz" derse 
tabii ki olabilir bence - ama bu o ekibin kararı olmalı, depo sorumlusu da 
yapılabileceğine ikna olmalı.

Tüm geliştiricilerin farm'a erişimi olması ise gereksiz ve çok sakıncalı : 
farm kararlı bir üretim sistemi, yapılacak en ufak hata tüm dağıtıma 
yansıyacak. 

Eren belirtmiş ama, bir kere de ben tekrarlayayım bu arada : Contrib 
farm'larının ikisine de çekirdek ekipten kimsenin erişim yetkisi yok. Sadece 
acil durumlarda (elektrik kesintisi, ağ sorunları, donanım problemleri gibi) 
müdahale etmek işi sistem yöneticimiz Taner'in sorumluluğunda, ama Farm 
yazılımına erişim hakkı sadece contrib depo yöneticisinin.    

Özetle demek istediğim şu : Buildfarm, "Pardus dağıtımının geliştiriciler için 
sunmuş olduğu geliştirme araçlarından [...]" biri değil. Aynen Pardus web, 
mail, ftp vs. sunucuları gibi Pardus kullanıcı ve geliştiricilerine hizmet 
eden bir servis, bu nedenle de kurulumu, bakımı ve işletilmesi özel bir 
dikkat, bilgi ve tecrübe istiyor.
--
İ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]