[Gelistirici] [RFC] Contribution/Pardus depoları

[Gökmen Görgen]

*(Alıntılamadığım kısımlara itirazım yoktur.)*

2009/6/5 Ozan Çağlayan <ozan at pardus.org.tr>

>    - İş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,


Bu konuda bir örnek vermek istiyorum. Şuan pardus deposunda GFTP, contrib
deposunda Filezilla var. Filezilla'nın durumu Firefox'unki gibi, yani pekçok
alternatif uygulamalara göre daha tercih edilebilir bir FTP yazılımı bence.
Bu durumda GFTP'nin yerine Filezilla ve bağımlılıklarının ana depoda yer
alması gerektiğini düşünüyorum. Böyle karşılaştırmalar yapıp bazı
uygulamaları katkı deposuna, daha uygun bir alternatifiyle yer değiştirecek
şekilde taşımamız gerekiyor bence. Tabi Filezilla - GFTP bir örnek.

   - 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,
>

İtirazım yok, sadece ileride alternatif ve KDE4 kullanmayan Pardus sürümleri
olursa, ya o sürümlerdeki masaüstü yöneticilerinin kararlı depoya girmesi,
ya da o sürümlerde DEFAULT olarak contrib deposunun ekli olması gerekecek.


Review süreci için:

   - 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.
>
>
Evet benim bu konuda şöyle bir fikrim var. Review sürecine katılan bileşen
sorumlusu, diğer review sürecine katılan paketçilere göre her halükarda daha
dikkatli geliştiricilerdir. Neden:
- Çünkü bileşen sorumlusu demek, kendi bileşenine has paketlerden ve bu
paketlerin hatalarından anlıyor demek.
- Kendi bileşenine ait paketleri zaten bir şekilde sıklıkla kullanıyor
demektir. Dolayısıyla o paketlerdeki kusurları, son kullanıcı olarak diğer
geliştiricilerden çok daha iyi kavrayabilir.
- Kendi bileşenine girebilecek potansiyel paketleri önceden denemiştir veya
o paketin nasıl bir faydası olacağını daha iyi kestirebilir.
- Bir de bileşen sorumlusu olduğu için, kendi bileşenine girecek paketleri
review ederken, diğer geliştiricilerden çok daha fazla dikkatli olur ve daha
fazla sorumluluk hisseder her halükarda.

Bu tip pozitif yönleri olduğu için, zaten yavaş işleyen review sürecini
hızlandırmak amacıyla şöyle bir yöntem yapabiliriz.
*- *Ya bileşen sorumlusu olmayan iki geliştiriciden ACK.
*- *Ya da bir bileşen sorumlusundan bir adet ACK.

Bu hem review sürecini bir nebze hızlandırır, hem de hızlandırma nedeniyle
oluşabilecek dikkatsizlik, yanlış review'i de az da olsa engeller.

-- 
gkmngrgn ~ http://www.gokmengorgen.net
-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090605/fbe87363/attachment-0002.htm>