[Gelistirici] Açık hatalar için test takımından faydalanmak

Serbulent UNSAL serbulent at pardus.org.tr
21 Oca 2009 Çar 20:06:59 EET


On Wednesday 21 January 2009 17:28:58 Onur Küçük wrote:
> Wednesday 21 January 2009 Tarihinde 16:04:17 yazmıştı:
> > Bence en uygunu bilgi isteyen/çözüm commit eden geliştiricinin buna
> > dikkat edip bu tag'ı eklemesi. Ama bu iş hata ile uğraşan adama ek yük
> > getirmesin vs. derseniz bugzilla ile uğraşan geliştiriciler veya ben de
> > yapabilirim bu işi.
>
>  NEEDINFO şu anda var diye biliyorum, komiti yapan / hatanın atandığı
> geliştirici de ihtiyaç duyduğunda kullanıyorsa ayrıca birinin "ya yok bu
> needinfo işaretlenmeli" demesine ne gerek var ?
>

Geliştiriler bu anahtar sözcüğü genelde ( ki her zaman değil ) bilgi 
eksikliğinden dolayı ( misal haftalarca/aylarca bilgi bekleyen hatalarda ) 
hata kapatırken kullanıyorlar.

Benim önerdiğim sistemde bu tagı kullanmak için haftalarca beklemeyelim. Bilgi 
beklediğimiz her durumda kullanalım/kullanılmasını teşvik edelim, böylece 
eğer mümkünse basit bir geri bildirim için zaman kaybetmeyelim diyorum.

Bu taglamayı yapmakta yetki/sorumluluk birinci derecede hata ile ilgilenen 
geliştiriciye ait olmalı bu kısımda görüşayrılığımız yok.

> > Bu arada başından beri Anahtar sözcük yazmak üzerinden konuşuyoruz işi
> > ama bu bilgi hatanın durum (status) bilgileri arasınada girebilir daha
> > kolay olur derseniz.
> >
> > >  Bir hatanın gerçekten başka bir hata ile aynı olduğu kararını, hata
> > > ile ilgili geliştiricinin dışında birinin yapması ne kadar sağlıklı
> > > olacak ? Benim hata kayıtlarında en çok yaşadığım sıkıntı aynı kayda
> > > birden fazla kişinin hatalarının aynı olduğunu zannedip "bilgi
> > > kalabalığı" yapması ve olayı iyice çorba etmesi.
> >
> > Bunu engelleyecek bir gümüş kurşunum yok, zaman, tecrübe ve sabır ile
> > olgunlaşacak bir süreç bu. Diğer taraftan burada [1] nasıl hata tekrar
> > edilebileceğine dair bir belge yazmıştım.  Buraya bu tür yanlışlıkların
> > nasıl fark edilebileceğine dair öneriler koyabiliriz. Ayrıca ben de test
> > takımını yönlendirirken bu konu ile ilgili daha özenli davranmalarını
> > isterim.
>
>  Burayı anlamadım ben. Tek tek olası bütün hata senaryolarını mı
> belgelendireceğiz ? Bir hata kaydında USB ID si hede olan kameradan görüntü
> alamıyorum dediğinde olayın içine kaç tane bileşen giriyor (xorg sürücüsü,
> xorg ayarları, kernel sürümü / i2c, oynatan program, oynatan programın
> bağımlılıkları, kernel sürücüsü ve dolayısıyla belki de pisi vs. vs.).
>
>  Genel bir bilgi koyacağım diyorsan olabilir tabi ki, ama iş hata ile
> uğraşan geliştirici için pirinç taşı ayıklama haline gelecekse mevcut iş
> gücünü iyice verimsizleştirir.
>

Yok hayır o belge hata tekrar etmek isteyen kişiler için basit bir yol 
gösterici. Benim söylediğim, bu işi yapacak kişiler hataların aynı olduğunu 
zannedip "bilgi kalabalığı" yapmasın diye bu belgeye hataları düzgün 
ayırabilmelerini sağlayacak ipuçları koymaktı.

> > >  Bu durumun üstesinden gelebilmek için bugzilla da zaten "DUPLICATE"
> > > diye bir sistem var. Bu sistemin üzerine "daha verimli" olacak bir şey
> > > ortaya koyabilecek miyiz ? Yoksa iyice hata kayıtlarının çorba olmasına
> > > mı sebep olacağız ?
> >
> > Burayı tam anlayamadım, konuştuğumuz sistem ile "DUPLICATE" arasında
> > ilişki kuramadım, açıklarsan sevinirim...
>
>  Herkes aynı hataya yorum yazacağına farklı hata kaydı olarak girer ve
> ilgili geliştirici sorunun aynı olduğunu düşündüğünde duplicate olarak
> işaretler. Ama bu demek değil ki her hata kaydı girildiğinde o hatayı
> tekrarlayan her kes birer hata girsin, geliştiriciyi çileden çıkarmaya
> gerek yok.
>
> > [1] http://tr.pardus-wiki.org/NASIL:Hata_onaylamak

Burada da bir yanlış anlaşılma olmuş. İlk posta da da söylediğim gibi sistemin 
amacı, eksik bilgi sebebiyle hataların uzun süre açık kalmasını engellemek. 
hata tekrar etmek değil.

Hata tekrar etme kısmı bu işin ancak ilk bölümünü oluşturuyor, nihai amacı 
değil.

-- 
İyi Çalışmalar;
 
Serbülent                                                                   



Gelistirici mesaj listesiyle ilgili daha fazla bilgi