Haftalık, aylık, 6 aylık ve yıllık olarak kapatılan, ayıklanan ve yorum yapılan hataların ne kadarının kimin tarafından yapıldığını aşağıda bulabilirsiniz 
- Tüm açık olan hataların genel durumu ve geliştiriciler üzerinde bulunan hata durumları
- Haftalık, aylık, 6 aylık, yıllık çözümlenen, yorumlanan ve ayıklana hata durumları.
- Haftalık ayrıntılı rapor
Haftalık, aylık, 6 aylık ve yıllık olarak kapatılan, ayıklanan ve yorum yapılan hataların ne kadarının kimin tarafından yapıldığını aşağıda bulabilirsiniz
- Tüm açık olan hataların genel durumu ve geliştiriciler üzerinde bulunan hata durumları
- Haftalık, aylık, 6 aylık, yıllık çözümlenen, yorumlanan ve ayıklana hata durumları.
- Haftalık ayrıntılı rapor
Daha izlenebilir bir hata takip sistemi için hata takip döngüsünde birkaç değişiklik yapmıştık. Tatil öncesindeydi fırsat bulup yazamamıştım, fırsat bugüneymiş…
Öncelikle daha önce kullanmadığımız TRIAGED ve ASSIGNED kavramlarından bahsetmek gerekebilir. Hatanın çözümü için gerekli tüm bilgiler rapor üzerinde mevcut ve geliştiricisinin çözmesine hazır halde ise TRIAGED anahtarı kullanılmakta. Bir geliştirici bir hatayı çözmeye başladığında ise ASSIGNED durumu kullanılıyor. Daha önceden de kullandığımız NEEDINFO anahtarı ise bilindiği gibi raporlayıcısından hata çözümü için bilgi istendiğinde kullanılmakta. Bu yeni kavramların gelmesi ile birlikte NEW olarak işaretlenip kalmış hatalar ise henüz hiç ilgilenilmemiş (hata ayıklama yapılmamış ve çözülmemiş) hatalar olmalı.
Sadece NEW ve NEEDINFO’yu kullandığımızda arada geçen hata ayıklama ve çözümü gibi iki uzun sürecin takibini atlamış oluyorduk. Ve hangi hatalar geliştiricisine hazır, geliştirici hangi hataları çözmeye başlamış, ne zamandır çözmeye çalışıyor gibi durumları kolay bir şekilde takip edemiyorduk. (Daha ayrıntılı süreci buradan görebilirsiniz.)
Ayrıca hataların önem derecesine göre hangi süreler içerisinde çözülebileceğini de tanımlamaya çalıştık. Böylece önceliklere göre, zaman bazlı iş yapabilir durumuna gelebileceğiz.
Bu sürecin izlenip daha çabuk oturabilmesi için dönemlik bir takım raporlar üretiyoruz: Şimdilik haftalık, aylık, 6 aylık ve yıllık olarak kapatılan, ayıklanan ve yorum yapılan hataların ne kadarının kimin tarafından yapıldığını basit anlamda da olsa görsel olarak görebiliyoruz:
- Tüm açık olan hataların genel durumu ve geliştiriciler üzerinde bulunan hata durumları
- Haftalık, aylık, 6 aylık, yıllık çözümlenen, yorumlanan ve ayıklana hata durumları.
- Haftalık ayrıntılı rapor
Bunlara şu anda kimin hangi hata ile uğraştığını, bir kişi üzerinde önem derecesi yüksek kaç hata bulunduğunu çıkaran raporlarda eklenebilir, bunları zamanla arttırıp daha izlenebilir bir ortam oluşturabiliriz.
Hata ayıklamalarının düzenli hale gelmesi, bu kavramların oturması ve sürecin iyi bir şekilde ilerlemeye başlaması ile birlikte daha kolay takip edilebilir, herkese yapılan işi daha iyi anlatabilir bir sistem oluşabilecek gibi görünüyor
Geliştirici adaylığını adım adım da olsa kolaylaştırma yolu içerisindeyiz. Pardus Stajyer’i olan arkadaşlarımız geliştirici adayı olmak istediklerinde yaptıkları projeler ile geliştirici adaylığına direkt olarak başvurup, yaptıkları işin tamamlanma durumu ve zorluğuna göre daha hızlı bir şekilde geliştirici olabilecekler.
Diyelim ki bir paket yaptınız ve bu paketin Pardus depolarına girmesini ve bu süreçten sonra bu paketin bakımını üstlenmeyi ve hatalarını gidermeyi sürdürmeyi düşünüyorsunuz Yapmanız gereken Pardus hata takip sisteminde yeni paket isteği ürününe bir hata açmak ve yaptığınız paketin kodunu bu hataya eklemek ve geliştirici başvurusunda bulunmak.
Aynı şekilde Pardus’ta bulunan herhangi bir paketin veya teknolojinin hata çözümünü, açılan hataya yama olarak gönderebilirsiniz. Herhangi bir teknoloji için yaptığınız iyileştirme ve yeni özelliği de yama şeklinde, ilgili teknoloji için yeni bir hata açarak ve yeni özellik önem derecesini seçerek raporlayabilirsiniz. Bu sayede bir hatanın çözümüne katkıda bulunmuş veya yeni bir özelliği Pardus teknolojilerine katmış olabilirsiniz.
Geliştirici başvurusuna ilgilendiğiniz hatanın veya hataların numaralarını hataya eklemeniz geliştirici adaylık sürecini büyük ölçüde hızlandıracaktır (junior job seçiminizi çoktan yapmış ve gerçekleştirmiş olacaksınız.)
Pardus üzerinde geliştirme yapan (üniversite projelerinde katkıda bulunanlar, Pardus dağıtımı ve araçlarını kullanarak geliştirme yapan kullanıcılar vb.) herkesin katılabileceği ve teknik tartışmaların yapılabileceği herkese açık bir liste açıldı.
Yukarıda bulunan amaçlar doğrultusunda, bilgi paylaşımında bulunmak isteyen kişileri bu listeye davet ediyoruz
Paket güncelleme açıklamalarında, Pardus bugzilla’sı ile ilgili bir hata çözüldüğünde bu hata artık pb#<hatanumarası> şeklinde belirtiliyor. Daha ayrıntılı bilgi için bakınız.
Sahipsiz paketlerin nasıl sahiplenebileceği ile ilgili bir yazı. Aynı zamanda nasıl paket bırakılacağı da anlatılıyor, ama paketlerimize sahip çıkalım bırakmayalım
Test belgeleri de yeni sürüm döngüsüne göre güncellendi.
Gecelik sürümlerin, resmi sürümlerin ve paket güncellemelerinin nasıl test edilecekleri ayrı ayrı anlatılıyor…
Her yazılım projesinin olduğu gibi Pardus’un da bir sürüm döngüsü mevcut Şimdiye kadar yazılı olmayan ama artık yazılı hale getirilen sürüm döngüsü ve gerekleri ortaya çıkmış durumda. Tabiki bu ilk versiyonu olduğu için yeni sürümler ile birlikte, üzerinde değişiklikler, çıkarıp eklemeler olacaktır.
Pardus’un şimdiye kadar çıkan sürümlerinde neyi ne kadar yapabildik yorumlarını sizlere bırakıyorum
Paket yapım belgesinde, indirilecek kaynak kodlar için nasıl mirrors eklendiği anlatılıyor.
Üst geliştiricide versiyon numaralarında rakam dışında değerler bulunduğunda bunların sıralaması nasıldır, pisi bunu nasıl algılar?
Pisi’de bulunan releaseFrom, releaseTo bu değerleri nasıl algılar?
Bunun ile ilgili belge güncellendi.
Geçen hafta Avrupa’nın soğuk havanın etkisine girmesi ile birlikte şöyle bir kuzeye açılmamın iyi olacağını düşündüm Geçen sene bu zamanlar İsveç’te gerçekleşen konferansın, bu sene Danimarka’da olması aslında gerçek sebep… Tabi neden bu kadar geç yazdım diyebilirsiniz, bilgisayarım fazla soğuğa dayanamadı ve anakartı yandı diyelim biraz ironik oldu ama öyle oldu ne yapalım…
Geçen sene gittiğimde çok iyi çok müthiş dediğim konferansta bu sene çok şey bulamadım, aynıydı genelde, ama son günü yine de işe yarardı diye düşünüyorum.
Neyse gelelim konferansın içeriğine: test, test otomasyonu, süreç iyileştirme gibi konuları kapsamaktaydı.
Girdiğim konferansların en yararlısı olarak söyleyebileceğim açık kaynak test tool’larını geliştirme süreçleri içerisinde entegre edebilmiş ve bu sistemi nasıl kullandığını anlatan kişinin konferansı idi. Geliştirme sürecinin farklı aşamalarında farklı test türlerinin ve takip sistemlerinin kullanılmasına olanak sağlayan ve sonuçlarını raporlayan bir döngünün ortaya çıkması için gerekli örnek araçları açıklamaktaydı… Bugzilla ile birlikte testlink ve sonar’ın entegre bir şekilde nasıl kullanılabileceğini anlattı.
Aslında sunumlardan yararlandığım kısımları açıklamadan önce, açık ve net olarak söyleyebilirim bu konferans sadece açık kaynak toplulukları için yapılmış veya bu uğur için çalışanlardan oluşan bir konferans değil, ama özellikle geliştirme süreçlerini iyileştirme ve yönetimi için ilk ve en önemli yapılması gerekli olan şeyin ortak olduğunu gördüm, nerede nasıl olursa olsun ilk öncelikli olan şey topluluk iletişiminin, yani bir amaç uğruna toplanmış kişilerin iletişiminin iyi olması gerekliliği idi. Her türlü bilginin görünür açık ve ulaşılır biçimde olması, takip edilebilmesinin önemi idi. Diğer önemli olan ve en motive eden şeyin topluluk bireylerinin bulunduğu ortamdan zevk alması, kendini arkadaş ortamında hissetmesi idi. Tabi bu demek değilki biri yanlış yaptığında düzeltme yoluna gitmeyeceğiz, amaan boşver diyeceğiz… Yapılması gereken biraz pesimist ve sabırlı davranıp karşımızdaki kişiyi kırmadan yanlış yapılan noktaları açıklamak.
Peki ya hikaye anlatmak; bir projenin geçmişini projeye yeni katılanlara tıpkı bir masal anlatıcı gibi anlatmanın, proje ve topluluk kültürünün aktarımı için en iyi yöntem olduğunu biliyor muydunuz? Ben duyduğumda çok şaşırdım…
Yeni bir şeyi açıklamak ve işler hale getirmek için ise: kolaylaştır, göster, örgütlen, öğret döngüsü. Biraz daha açmak gerekir ise; yeni bir şeyi en kolay şekilde açıklamak için , taslaklar hazırlayarak sunmamızın gerektiği, sunum sonrasında oluşan geri bildirimler ile gerekli değişiklikleri yapıp, ortak bir grup kararına varıp, daha sonra bu alınan kararları bir belge haline getirip, ilgili kişilerin okumasına ve öğrenmesine açık hale getirmek.
Diğer sunumlardan biri ise geliştirme döngüsünü sekteye uğratan sorunlar idi, bunların en göze çarpanları:
Bir de birkaç foto koyalım
http://cartoontester.blogspot.com/
Tüm kaynak ve derlenmiş depolarımızı anlatan belgeye buradan ulaşabilirsiniz.
Henüz depo kavramlarından bahsedilmiş durumda, depo süreçleri ile ilgili belgeyi ise bir süre sonra bulabileceksiniz…
Özgür yazılımların can damarı olan sürüm kontrol sistemlerinin kullanımı ile ilgili bazı önemli bilgileri bir belgede topladık. Bu kadarı tabi ki yeterli değil bunun için yapılması gereken en güzel şey büyük bir özgür bir yazılım projesinin sürüm kontrol commit listesini takip etmek…
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
[2] http://svn.python.org/view/
[3] http://websvn.kde.org/
[4] http://git.gnome.org/browse/
Ubuntu’ya bak yaw alışveriş merkezlerinde bile CD dağıtıyor [1], yılbaşı partisi de ayrı tabi [2]….
[1] CD dağıtımı
[2] Yılbaşı partisi
Adayları biraz daha özgür bırakmak adına süreçte bazı değişiklikler yaptık. Bugzilla’da junior jobs anahtarı ile işaretlenmiş hatalar bulunacak ve geliştiriciler junior job olabilecek hataları bu anahtar ile işaretleyebilecek veya direk olarak akıllarına gelen junior jobları bu anahtar ile raporlayabilecekler.
Adaylar kısmında ise şu şekilde bir değişiklik oldu; quizleri onaylanan adaylar, junior jobs anahtarı ile işaretlenmiş hataları gözden geçirecek ve kendilerine junior job seçecekler ve bunu seçtiklerini kendi adlarına açılmış olan hatada ilan edecekler. Daha sonra bu iş doğrultusunda bu adaya bir mentor atanacak ve playground izni alacaklar. Bu iş süresince mentor adayı uzaktan gözlemleyecek ve gerekli gördüğü yerlerde adayın raporu üzerinden yorumda bulunacak. Bkz. Nasıl Katkıcı Olunur?
Not: JUNIORJOBS anahtarı bugün eklendiği için henüz açık hata bulunmamakta
Bugzilla ile ilgili ek bir hatırlatma: Yeni paket istekleri Paketler /Packages -> Yeni Paket İsteği /New Package Request bölümünden yapılmakta.
Sürümler için bulunan ürünlerde yer alan” Paket listede yok / Package is not in the list” bileşeni sisteminizde bulunan ve hata aldığınız, fakat raporlarken bugzilla’da bulamadığınız paketlerin hataları için kullanabileceğiniz bir bileşen…
Bugzilla’da sınıflandırma yöntemini kullanmaya başladık.
Bu yapıda çeşitli gruplar ortaya çıktı:
Hatalar için
Pardus Topluluğu süreçlerinde kullanılan düzenli raporlamalar için (Bu grup hata raporlama amacı ile kullanılmamaktadır.)
Bu grupları ve altlarında bulunan ürünleri aşağıda daha net görebilirsiniz:
Daha ayrıntılısı ve her ürünün açıklaması için : Bugzilla Pardus
2011 Beta sürümü ile boğuştuğumuz bu günlerde hata girmek ve bize yardımcı olmak isteyen herkes için
Bu yazı iyi bir hata raporunun nasıl olması gerektiğini açıklamaktadır.
Kısaca anlamı ile hata raporu geliştiricinin uygulamadaki hatanın tekrarlayabilmesi için önemlidir. Geliştirici raporu kullanarak uygulamanın hatasını anlayabilene kadar hatayı tekrarlayan kullanıcıdan bilgi istemektedir.
Hata raporlarında gerçek sorunun ne olduğu açıkça anlatılmalıdır, histerik davranılmamalıdır (“Bilgisayarın başındaydım ve herşey o anda oldu”) ve gereksiz kurgulara yer verilmemelidir (“Sanırım sorun buradan kaynaklanıyor”). Düşüncelerinizi aktarabilirsiniz, fakat bunları efsaneleştirmeye çalışmayınız.
Hata raporlamanızın amacı hatayı çözüme kavuşturma isteğinizdir. Geliştiriciye karşı kötü sözler söylemenin veya kasten hatanın çözülmesine engel olmanın hiç bir anlamlı ifadesi bulunmamaktadır: yazılan programda hata almış olabilirsiniz, bu yüzden problem yaşıyor ve sinirlenmiş olabilirsiniz fakat hatanın çabucak çözüme kavuşması için yapmanız gereken en iyi şey hata için gerekli olabilcek tüm bilgiyi açık bir dil ile rapora aktarmaktır. Unutulmamalıdır ki geliştiricilerimizin büyük bir kısmı gönüllü olarak çalışmaktadır ve raporlayıcı görgü kurallarını aştığında ve kötü sözler sarf etmeye başladığında, geliştiricilerimizde kibar davranmayı bırakabilmektedir.
Geliştiriciye biraz akıl yürütebilmesi için fırsat tanıyın: hatanın özet ve açıklamalarında olabildiğince açık bir dil kullanmaya ve bilgi vermeye çalışın. Eğer gerçekten uygulama tamamıyla çalışmıyorsa,büyük bir ihtimal geliştiricisi bunu farketmiş ve mutlaka bunun üzerinde çalışıyordur. Bu yüzden uygulamanın tamamıyla çalışmamasının kullanıcı kaynaklı olup olmadığını anlamaya çalışın. Daha önce değiştirmiş olduğunuz bir ayar dosyası, update sırasında bilgisayarın ani bir şekilde kapatılması gibi bir durum söz konusu olabilir.
Hata takip sisteminde birçok hata bulunmaktadır, eğer hata aldığınız uygulama daha önce raporlanmış ise, bu hatayı tekrar raporlamamalısınız. Fakat daha önce raporlanmış hatayı daha iyi açıklayan bir yorum yazabilirsiniz. Bu hatanın geliştiricidinin işine yarabilecek bir durumdur.
Uygulama kullanım yardımı almak için hata girilmemelidir, gerekli yardım kullanıcı listeleri ve forumlardan alınmalıdır.
Geliştiricinin sizin uyguladığınız yöntemin aynısını izleyerek hatayla karşılaşmasını sağlayın, amaç burada sadece geliştiriciye hatayı tekrarlatmaya çalışmaktır. Eğer gözleri önünde programın çalışmadığını görürlerse, bununla ilgilenmek için heyecan duyacaklardır.
Bu yüzden açık bir şekilde ne yaptığınız anlatın. Eğer grafiksel bir uygulama ise, hangi butonlara bastığınızı, hangi bildirimlerde bulunduğunuzu belirtin. Eğer komut satırından çalışan bir uygulama ise hangi komutları sırası ile kullandığınızı sırası ile yazınız, eğer mümkünse komutları yazdığınız ve sonuçları aldığınız alanı kopyalayınız ve rapora ekleyiniz.
Geliştiriciye uygulama ile ilgili aklınıza gelen her bilgiyi verin. Eğer uygulama bir dosya okurken hata aldıysanız mutlaka bu dosyayı ek olarak ekleyin. Gerekli log dosyalarını da eklemeyi unutmayın.
Geliştiriciye gerekli bilgileri ve bildirimleri gönderdiniz, geliştirici hatayı tekrarlamaya çalıştı ve her şeyin yolunda olduğunu gözlemledi. Büyük bir olasılıkla tüm bilgileri geliştiriciye göndermediniz, belkide bu hata tüm bilgisayarlarda tekrarlanayamayan bir hataydı. Aynı zamanda geliştiricinin bir sorunla karşılaşmamasının nedeni anlayış biçimi farklılığından da kaynaklanıyor olabilmektedir. Sizin için yanlış olan bir durumun geliştiricisi için uygulamaya eklediği yeni bir özellik veya davranış olabilmektedir.
Bu yüzden hatayı aldığınızda ne olduğunu anlatın, ne gördüğünüzü açıklayın. Gördüğünüz şeyin size neden yanlış geldiğini anlatın; diğer bir değişle uygulamadan ne beklediğinizi açıklayın.
Eğer hata mesajları gördüyseniz, bunları rapora mutlaka ekleyin. Hata measjını eksiksiz bir şekilde göndermeye özen gösterin. Örneğin hata mesajlarında bulunan sayılar, geliştiricinin gerekli bilgiyi elde edbilmesi için önemli olabilmektedir. Bu aşamada gerliştirici problemi çözmeyi değil, bulmayı düşünmektedir. Sizin göndermiş olduğunuz hata mesajları doğrultusunda neyin kötü gittiğini anlamaya çalışmaktadır.
Bir hata ile karşılaştığınızda bir çok farklı yapılacak şey aklınıza gelebilir. Fakat bunların bir çoğu problemi daha kötü duruma getirebilir.
Kullanıcılar genellikle tetikte av bekleyen bir aslan gibidir. Aslan avı gördüğünde hızlı bir hamle ile etkisiz hale getirir. Fakat bu durum bilgisayarda hata alındığında uygulanması uygun olmayan bir yöntemdir. Bu durum için, aslan olmak yerine geyik olmak daha iyidir. Geyik düşmanı gördüğünde hareketsiz olarak kalır ve dikkat çekmemek için hiç bir şey yapmaz.
Bilgisayarda problem ile karşılaştığınızda, ne yapıyorsanız bırakın. Hiç bir butona, tuşa basmayın. Ekrana bakın ve herşey normale dönene kadar bekleyin, bu sürede olan olayları bir yere kaydedin. Daha sonra dikkatli bir şekilde ekranda çıkan görüntüyü inceleyin ve sizin için en güvenli olduğunu düşündüğünüz yöntemi seçin. Bilgisayar karşısında istenmeyen bir durum ile karşılaştığınızda (donma, takılma çökme vb.) bir refleks geliştirin.
Hata ile başedebildiğiniz noktada (İlgili uygulamayı kapatmış olabilirsiniz, bilgisayarı yeniden başlatmış olabilirsiniz, vb.), hatayı yeniden tekrarlamayı deneyin. Geliştiriciler birden fazla kez tekrarlanabilen hataları severler. Ve mutlu geliştiriciler daha etkili ve hızlı hata çözerler
Basit hatalar, belirli bir sırada yapılan işlemler sonrasında ortaya çıkan hatalardır. Fakat bazı hatalar haftada bir, ayda bir veya herhangi bir zamanda ortaya çıkan hatalardır.
Çoğu rastgele oluşan hata aslında rastgele olmayabilir. Çoğunun bazı mantıksal ifadesi bulunmaktadır. Bazıları makinenin hafızasının yetersiz kalmasından, bazıları kritik bir dosyaya yanlış zamanda yazmasından meydana gelebilir. Bu yüzden hatayı aldığınız anda açık olan tüm programları açıklamanız yararlı olabilmektedir. (Örneğin: Genellikle Gimp açık iken ekran donuyor.)
Ayrıca eğer geliştirici hatayı tekrar edemiyor ama siz edebiliyorsanız, bir şekilde sizin bilgisayarınızın geliştiricininkinden farklı olmasından kaynaklanıyor olabilir ve bu fark hataya neden oluyor olabilir. Bu hatalar genellikle donanıma bağlı olan hatalar olmaktadır, bu durumda hata aldığınız uygulamanını bağlı olduğu donanımların bilgisiniz hata raporuna eklemek çok yararlı olacaktır.
Hata raporunun açık ve temiz bir dil ile yazılmış olması önemlidir. Geliştirici sizin ne söylediğinizi anlamadığı sürece siz hiç bir şey söylememişsiniz demektir.
Thu May 24 13:35:30 2012
Pardus e-dergiyi okumak için buraya tıklayın.
