[Gelistirici] kararli depoya paket gecis sureci

[Ekin Meroğlu]

Merhaba;

Friday 19 December 2008 tarihinde, Doruk Fisek şunları yazmıştı: 
> Fri, 5 Dec 2008 14:52:22 +0200, Ekin Meroğlu <ekin at pardus.org.tr> :
> > [Tekrar yazılması gereken] Depo politikasına göre acil durumlarda
> > paketçisine ulaşılamayan paketlerde ikinci derece sorumlu olmak ve
> > bileşenlerdeki gelişmelere nezaret etmek dışında bir işi yok :-)
>
> Bence degil. Bu zaman icinde dejenere olmus depo politikasina gore :)

Onun için tekrar yazılması gereken dedim, ben de şu anki halinin yanlış ve çok 
eksik olduğunu düşünüyorum, onun için sonunda smiley var.

> Bilesen sorumlusu gercekten bilesen sorumlusuysa, "nezaret etmek"
> disinda bir katkisi olmali ortama.
>
> Ornegin kendi bileseni cercevesinde,
> - "Bakicisiz" paketlere bakici bulmak
>[...]
> - Kendi bileseni ve icindeki paketlerle ilgili her tur karar verilirken 
> birinci derecede soz sahibi olmak.
> Hakkiyla yapilmasina izin verilen bir bilesen sorumlu sisteminin 
> getirecegi yararlari listelemeye kalktim ama neredeyse "dişlere iyi
> gelir, hatta aganiginaganigi"ye donecegi icin vazgectim :)

Ben bunların hiçbirine karşı değilim teoride. Ama her kararı bileşen sorumlusu 
tek başına verirse bu bileşen sorumlularının birbirinin ayağına basmaması 
için bir mekanizma gerekecek - bence sürüm yöneticisi ya da depo sorumlusunu 
da içeren düzgün bir politika ile çözülecek bir sorun bu.Kaldı ki şu anda 
bileşen sorumlusu olmak isteyene de kimse dur demiyor (örn. İnanç Yıldırgan 
Font bileşeni sorumlusu oldu yakın zamanda), bileşeni ile ilgili bir karar 
vermek / değişiklik yapmak isteyene de. 

Açıkçası sürüm yöneticisi olarak kimseyle yetki paylaşmak istemiyor, ali kıran 
baş kesen olmayı tercih ediyormuşum gibi bir algı var özellikle bu postada, 
anlamakta güçlük çekiyorum. Evet, depo ve sürüm sürecinde bazı kararların 
hızlı alınması gerekiyor, bazı düzeltmelerin tek elden "böyle olmalı" kararı 
verilerek yapılması gerekiyor. Şimdiye kadar kararlarda geliştiricilerle 
tartışmaya, herkesten fikir almaya çalıştığımı düşünüyorum, ama acil 
durumlarda da sorumluluğu alarak müdahale ettim tabii ki. Ama bu tip 
eleştirilerde, geliştirici listesine attığım maillere cevap alma oranımın 
bile neredeyse 5'te 1 olduğunu da göz önüne alırsanız sevinirim - ortada her 
türlü sürece dahil olmak, çözüm önerileriyle gelmek için kendini yırtan bir 
kitle var da, ben (ya da bir başka geliştirici) kimseye söz hakkı vermeden 
aklına eseni yapıyor gibi bir durum yok. Birileri bir karar veriyor, çünkü 
başka karar veren, fikir belirten, hatta kararlar verildikten sonra "niye" 
diye soran bile yok.      

> > Ama bu, depo bağımlılıklarının aynı bileşen içinde kaldığını
> > farzedersek mantıklı ki şu anki durum buna yakın bile değil - 2007 ->
> > 2008 geçişinde depoyu bileşen bileşen paylaşmak tam anlamıyla mümkün
> > olmamıştı mesela, her bileşenin bağımlılık ağacı alakasız yerlere
> > gidiyordu.

Bunları bileşen sorumlularına daha fazla sorumluluk ve görev vermeyelim diye 
yazmadım, "bileşen sorumlusu bileşenindeki paketi alsın, derlesin, test 
etsin" önerisine karşı söyledim. Birkaç kere anlatmaya çalıştığım nedenlerle 
en azından farmın on kişi tarafından hep beraber çalıştırılabilmesi mümkün 
görünmüyor.

> Bu eskiden de boyleydi. O zaman bilesen paylasilabiliyor ve bu sistem
> isleyebiliyordu. Bence gecerli bir neden degil soyledigin.
> Atalarimiz bosuna "böl ve yonet" dememisler. Eger tum dagitimi buyuk
> bir yun yumagi olarak gorursek elbette yonetilemez ve icinden cikilamaz
> hale gelir.

Baştan beri ben de bileşen sorumlularının daha fazla yetki ve sorumluluk 
almasının iyi olacağını savunuyorum.

> Su haliyle senin soyledigin, paketleri birbirinden ayiramiyoruz, o
> zaman dagitimdan tek kisi sorumlu olsun, o da her isin altindan
> kalksina karsilik geliyor. 

Ben böyle bir şey söylemiyorum. Bileşen sorumluları kendi bileşenlerinde 
birinci dereceden söz sahibi olsunlar, ama bu yeterli değil. Bu ekibin 
(bileşen sorumlularından oluşan) nasıl uyumlu çalışacağını da süreç haline 
getirmek gerekiyor - yoksa bir sürüm/depo yöneticisi yerine 10 sürüm 
yöneticisi koymaktan faklı bir işi yapmıyorsun, bu kadar birbirine bağlı 
alanlarda çalışırken bu da tartışma, birbirlerinin yaptığını bozma vs ile 
daha çok zaman kaybetmeye neden olacak, işler daha da yavaşlayacak diye 
düşünüyorum. 

Yine aynı nokta, bir daha tekrarlayayım :  

Bir süreci değiştirirken sırf eskisinden memnun olmamak yeterli değil, 
eskisinden ne öğrenebiliriz diye de bakmak gerekiyor. 

Ben iki (bir başka ekipte de üç) kişiyle ortak farm yönettim, farmın böyle 
yönetilmek için fazla manuel olduğunu, şu anki ve yakın gelecekteki depo 
büyüklüğü ve güncelleme sıklığının en azından farmın birkaç kişi tarafından 
çalıştırılmasını gerektirmediğini öğrendim. Eğer bir gün farm on kişi 
tarafından birlikte yönetilecekse oldukça temel süreç ve yazılım 
değişikliklerine ihtiyacımız olduğunu biliyorum ve bunu anlatmaya 
çalışıyorum.

Yine uzunca bir dönem herkesin commit ettiği bir depoyu derledim, bunun da 
sorunsuz olmadığını, amaç yükü paylaşmak ise başka yolları olduğunu 
söylüyorum. Burada da kimsenin elini tutmuyoruz durumu var aslında - 2007 
deposuna uzun süre 4, sonra değişikliklerle başka 4 kişinin yazma hakkı 
vardı, 2008'e iki kişinin yazma hakkı var : bu sefer de nasılsa yapan var, 
commit etmediyse bir bildiği vardır düşüncesiyle diğerleri kommit yapmıyor 
(bu denklemin her iki tarafında da bulundum). Burada da kararlı sürüm bakım 
ekibi ve bileşen sorumlularını da içeren düzgün bir politika yazılmadan, en 
azından temel konularda bir ortak noktaya varılmadan yazma hakkının 
açılmasının ortalığı karıştıracağını düşünüyorum.

Özetle (farmın teknik gereklilikleri dışında) hiçbir konuda geliştiricilerin 
daha fazla sorumluluk almasına, her anlamda "iş yapmasına" karşı değilim, ama 
o sorumluluğu ve işi verirken kurallarını koymazsak sonuç alabileceğimizi 
düşünmüyorum. "Bileşen sorumluları kendi bileşenlerini merge etsin" demek 
yetmiyor, "bileşen sorumluları kendi aralarında şöyle iletişim kuracak, sorun 
çıktığında böyle halledilecek, diğer geliştiricileri gelişmelerden şu şekilde 
haberdar edecek" demek lazım. Bugüne kadar bunu yapmadık, ama artık bir 
değişiklik yapacaksak kitabına uygun yapmak lazım.
 
--
İyi Çalışmalar;
Ekin Meroglu <ekin_at_pardus.org.tr>