[Gelistirici] [RFC] Contribution/Pardus depoları

Ozan Çağlayan ozan at pardus.org.tr
5 Haz 2009 Cum 09:02:05 EEST


Selam,

Bilmök'teki geliştirici toplasında belirlendiği üzere Ekin, Onur ve
benim bir araya gelip çıkarmaya çalıştığımız kısıtları dilim döndüğünce
anlatmaya çalışacağım. Fikirlerinizle daha da olgunlaşıp nihai bir
politikaya dönüşeceğine eminim. Aslında tam ayrım kısıtlarından ziyade
ilk planda "Hangi paket ana depo adayıdır?" sorusunun cevabından yola
çıktık.


    - Paket temel masaüstü kullanımı için eksik bir işlevi tamamlıyor,

    - İşlevsellik bakımından yakın/aynı paketler ana depoda yer alabilir
ancak bu aynı işi yapan onlarca uygulamanın depoda yer alacağı anlamına
gelmez. Uygulamaların kaliteleri/geliştirilme durumları/yetenekleri
önemli kıstaslardır,

    - Paketin tam veya tama yakın Türkçe yerelleştirmesinin olması
tercih edilir,

    - Paketlenen uygulamanın, açılan hatalarla ilgilenen aktif bir
upstream'inin olması tercih edilir. Etkin bir upstream, bizim paketi en
iyi şekilde desteklemeye çalışacağımızın bir göstergesidir. Ancak
gerçekten çok önemli ve kilit bir uygulama ise, etkin bir upstream'inin
olup olmaması veya projenin gelişiminin durumu istisnalara tabi tutulabilir,

    - Çekirdek sürücüleri, çok kalitesiz, sorunlu, alternatifli olmadığı
sürece ana depoda yer almalıdır,

    - Yine oyunlar, bazı temel kısıtları sağlıyorsa (KDE menüsünden
kolayca erişilip, tıklanıp, sorunsuzca başlatılabiliyorsa, vs.) ana
depoda yer almalıdır, (Bu kısıtlar konusunda Onur'un eklemeleri olabilir),

    - Ana depoda sadece bir adet masaüstü ortamı
desteklenmektedir/bulunmaktadır bu da şu anda KDE4'tür. Bu ortam
dağıtımın öntanımlı masaüstü ortamıdır,

    - Perl ve Python gibi betik dillerini zenginleştiren modülleri
genelde küçük, zararsız kütüphanelerdir. Bağımlılık sorunları olmadığı
sürece, geliştirme ortamını zenginleştirmek açısından ana depoda yer
almaları tercih edilir,


Bu yukarıdaki maddeler ilk planda aklımıza gelenler. Bir paketin hangi
depoya gideceğine ise review sürecinde karar verilecek.

Review sürecinde de bazı değişiklikler düşündük, öncelikle:

    - Bileşen sahipleri belirlenecek,
    - Bir paketin depoya girebilmesi için 2 tane herhangi ACK, 1 tane de
bileşen sorumlusundan gelecek ACK alması gerekecek,
      Örneğin desktop.fonts bileşenine ait bir paket 2 ACK aldıktan
sonra, desktop.fonts sorumlusundan ACK alması gerekecek. Bileşen
sorumlusundan gelecek ACK hiyerarşik olarak yukarıya çıkabiliyor, yani
bu örnek durumda desktop bileşeninin sorumlusunun ACK'ı da geçerli
olacaktır.

Tüm e-postada yazanlar geliştirmeye ve değiştirmeye açıktır,
fikirlerinizi bekliyoruz.




Gelistirici mesaj listesiyle ilgili daha fazla bilgi