On Fri, 12 Aug 2011 12:00:59 +0300, Fatih Aşıcı <fa...@pardus.org.tr> wrote:
12.08.2011 10:34, H. İbrahim Güngör yazmış:
On Fri, 12 Aug 2011 10:32:41 +0300
Renan Cakirerk<re...@pardus.org.tr> wrote:
Merhaba,
Selam,
Git'in nimetlerinden yararlanmak üzere SVN depolarımızda bulunan ve bir
süredir [1] adresi altında da geliştirilen YALI'yı artık git depomuz
altında geliştirmek istiyoruz.
Depoda "yali.git" projesi açtık ve commitlerin gideceği e-posta listesi
olarak halihazırda bulunan ve 100 kadar üyesi olan ama uzun! zamandır
kullanılmayan "yali e-posta listesi"ni [2] hortlatmaya karar verdik.
commitler ve tartışmaların aynı liste üzerinde gitmesi listenin takibini
çok
zorlaştırır. commitler için neden uludag-commits listesini
kullanmıyorsunuz?
isteyene yali ile ilgili commitleri filtreler.
proje başına devel ve commit listelerinin olması bence iyi bir şey. Şu
anki durumda pisi projesini kullanmak isteyen bir X dağıtımı geliştiricisi,
gelistirici ve uludag-commits listelerini takip
etmek zorunda. Bu da o geliştiricinin hiç ilgisi olmadığı halde Pardus ile
ilgili tüm tartışmalar/commitler arasında pisi ile ilgili olanları ayıklamak
zorunda kalmasına neden oluyor.
Filtreleme demeyin bence (ki zaten gelistirici'yi neye göre
filtreleyecek?). Birden fazla hatta değişik yerlerde e-posta istemcisi
kullanmak zorunda kalan birisi için -hele ki sağlayıcısı sieve
desteklemiyorsa- bu çok zor olabiliyor.
Fatih ile aynı fikirde düşünüyorum.
Diğer açık yazılım projelerinde de genellikle izlenen yöntem bu zaten. En
azından devel ayrı olmalı. Code review ile kastedilen de commit mailine
reply edilerek yapılcak bir iş değil anladığım
kadarıyla. Review, git-send-mail ile gönderilen mail'e yapılır ve commit
*yapılmadan* öncedir. Sonra olsa pek bir işlevi olmaz zaten.
Review için ise herkes kendi git alanında işini yaptıktan sonra redmine
üzerinde zaten hali hazırda açılmış issue üzerinden review isteğinde bulunur
ve orada bulunan code review aracı üzerinden review yapılabilir ve daha sonra
proje lideri, master branch'e commit edebilicek kişi yada kişilerce onaylanır
ve alınır şeklinde bir süreç oluşturulmuştu. Bunun tartışması git-flow
belgesini çıkarırken yapmıştık diye hatırlıyorum [1].
[1]
http://svn.pardus.org.tr/uludag/trunk/doc/en/developer.pardus.org.tr/source/guides/releasing/repository_concepts/git-workflow-en.rst
--
Semen Cirit
TUBITAK/BILGEM - Pardus GNU/Linux
http://developer.pardus.org.tr/
_______________________________________________
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici