Test Dünyasında Neler Oluyor ( Bölüm-4 Ubuntu )

Bu serinin son bölümünü Ubuntu oluşturuyor. Şu ana kadar incelediğim dağıtımlar arasında en iyi test süreçlerine sahip olanı mıdır emin değilim ama bu konudaki en iyi dokümantasyona sahip dağıtım olduğunu söyleyebilirim.

Ubuntu QA takımına ait 2 farklı anasayfa bulunuyor [1] [2] , bunlardan ikincisi bu girdi yazıldığı tarihte henüz tam olarak aktif değildi. Alt QA takımlarına ait siteler henüz işlerlik kazanmamıştı.

Bu nokta da QA takımına biraz daha yakından bakalım. Ubuntu QA takımı aktif olarak iş yapmaktan çok QA ile ilgili iş yapan ekiplerin kordinasyonundan sorumlu. Hata ayıklamak (çözmek değil), Testler, Brainstorm arayüzü gibi değişik pek çok alandan sorumlu QA takımı.

Hata Ekibi'nin [3] yaptığı işler ayrı bir yazı konusu olabilecek kadar fazla olduğundan burada detay vermeyi düşünmüyorum. Asıl sorumluluğunu hata sınıflandırmak olarak tanımlayabileceğimiz ekip bu başlık altında hataları uygun kişilere atama, hataları birbiri ile ve upstream ile eşleştirme, Bütün hataların istenilen temel bilgileri içermesini sağlamak, hata onaylamak gibi pek çok işi yapıyor. [4] [5]

* Pardus tarafına baktığımızda gönüllü sayısının azlığından dolayı aynı kişiler ile işler yürüyecek olsa da organizasyon olarak test ve hata ayıklama işlerini birbirinden ayrıştırmak mantıklı göründü bana da.

Gelelim Ubuntu Test Takımına; Takımın ana sayfası [6] oldukça düzenli ve özet bilgileri içeriyor. Öncelikle bir TODO listeleri bulunuyor [7] yapılacak işleri özetleyen. Bunun yanında bir sonraki sürümde yapılacak işler için de ayrı bir yol haritası [8] tutuyorlar.

Güncellemelerden çok yeni çıkacak sürümün testlerine yoğunlaşmış durumdalar, 6 aylık sürüm periyotları olduğunu düşünürsek bu çok garipsenecek bir durum değil aslında. Güncelleme testlerini ayrıca inceleyeceğiz, öncelikle sürüm testlerine bakalım.

Sürüme kadar olan süreçte oldukça fazla sayıda ön sürüm çıkartıyorlar ( Örneğin bu yazı yazıldığı tarihte 4 tane Alfa sürümü mevcuttu ). Testler için ayrı bir makina veya disk ayrılmasını istiyorlar.

Testler 2 safhada gerçekleşiyor. İlki Smoke Test [9] adı verilen ara sürüm çıkmadan önceki 4-5 günlük periyotta gerçekleşen testler. Bu testlerde herbir ara sürüm için show-stopper olan sürümün temel işlevlerini test ediyorlar. [10]

Ara sürümün çıkmasının ardından ise image validation olarak adlandırılan daha geniş kapsamlı testlere geçiliyor.

Testlerin raporlanmasını Launchpad üzerinden ISO Tracker [11] adındaki bir web uygulaması ile gerçekleştiriliyor. ISO Tracker ile güncelleme yolu ile sürüm yükselten testçilerin test etmesi mümkün olmayan ISO üzerinden farklı biçimlerdeki kurulum alternatifleri test ediliyor ve hatalar raporlanıyor. Burada Launchpad in merkezi hata takip yapısının sunduğu avantajlardan faydalanılarak yeni hata girişi ve var olan hataların takibi kolaylıkla mümkün olabiliyor. Bunun yanı sıra ISO testlerindeki onay bekleyen hataları da wiki aracılığı ile listeliyorlar. [12]

Bunun dışında kalan testler için uyguladıkları metodlara ait dokümanlara ulaşamadım ancak kullandıkları test yönergelerine [13] ulaşılabiliyor. Ayrıca bu test caselerin neleri kapsadığını görebilmekte güzel. [14] Bu noktada son olarak dikkatimi çeken bölüm eklenecek olan yeni özelliklere ilişkin herşey ( uygulamasından testine kadar ) wiki aracılığı ile detaylı bir biçimde paylaşılıyor. [15]

Şimdi de sürüm içi güncelleme testlerine bakalım. Bu testler konusunda oldukça hassas davranıyor Ubuntu. Her güncellemeyi almıyor kararlı sürüme [16] ( Sık sürüm çıkartmanın bir başka avantajı ) genellikle çok önemli bir hatayı çözüyor olması gerekiyor. Hatta güvenlik güncellemelerinde bile aynı seçilikle yaklaşıyor [17] kararlı sürüm güncellemelerine.

Bu süreçlerin her ikisinde de özel durumlar haricinde sürüm güncellemesi yapmıyor, sadece hatayı çözen yamayı mümkün olduğunca minimal bir şekilde backport ediyorlar.

Gelelim bizim için asıl önemli nokta olan güncelleme prosedürüne;

1- Öncelikle hatanın o anki geliştirme sürümünde düzeltildiğinden emin olunur.

2- Güncellemenin çözdüğü hata raporuna gerekli açıklama girilir. Bu açıklamada hatanın etkileri, geliştirme sürümünde nasıl çözüldüğü, hatanın nasıl tekrarlanabileceği ve yamanın yaratabileceği olası yan etkiler anlatılır. Ayrıca hatayı çözen minimal yama da eklenir. Eğer bu yamayı hazırlamak çok uzun bir süre alacaksa SRU ( Stable Release Updates ) takımından onay alınır ( anladığım kadarıyla sürüm güncellemesi için alınıyor bu onay ).

3- Paket aday olarak işaretlenir ve SRU takımına haber verilir. Yöneticiler tarafından onaylanan paket derlenir ve test edilmek için hazır hale gelir.

4- SRU onaylama takımı açık olan verification-needed etiketli hataları [18] düzenli olarak inceler ve onay veya ret kararı verir.


[1] https://wiki.ubuntu.com/QATeam
[2] http://qa.ubuntu.com/
[3] https://wiki.ubuntu.com/BugSquad
[4] https://wiki.ubuntu.com/Bugs/HowToTriage/
[5] https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
[6] https://wiki.ubuntu.com/Testing
[7] https://wiki.ubuntu.com/Testing/TODO
[8] https://wiki.ubuntu.com/QATeam/RoadMap
[9] https://wiki.ubuntu.com/Testing/ISO/Schedule
[10] https://wiki.ubuntu.com/Testing/ISO/Smoke
[11] http://iso.qa.ubuntu.com/qatracker/
[12] https://wiki.ubuntu.com/Testing/FixesToVerify
[13] http://testcases.qa.ubuntu.com/
[14] http://testcases.qa.ubuntu.com/Coverage/Overview
[15] https://wiki.ubuntu.com/EncryptedPrivateDirectory
[16] https://wiki.ubuntu.com/StableReleaseUpdates#When
[17] https://wiki.ubuntu.com/SecurityUpdateProcedures
[18] http://people.ubuntu.com/~ubuntu-archive/pending-sru.html

9 Şubat 2009

Test Dünyasında Neler Oluyor ( Bölüm-3 Fedora)

Fedora kalite güvence ekibinin 4 ana sorumluluğu bulunuyor; Hata sınıflandırma, Güncelleme testleri , Sürüm testleri, Test araçları geliştirmek.


Hata sınıflandırma bölümünde hataların doğru insanlara atanmasını sağlıyorlar.

Güncelleme testlerini Bodhi [1] adındaki web tabanlı bir yazılım ile gerçekleştiriyorlar. Bu yapının önemli avantajlarından birisi detaylı ölçüm ve istatistikler tutmaya izin vermesi [2]. Konu ile ilgili ilginç bulduğum ilk nokta yeni paketlerin test edilip edilemeyeceği kararını paket için güncelleme isteyen geliştirici belirliyor. İkinci ilginç nokta ise paketlerin testi dondurulmuş belirli bir depo durumu içinde değil tek tek paketler üzerinde yapılıyor olması.

Sürüm testleri üzerinde oldukça detaylı çalışılan bir süreç, 2 temel kategoriye ayrılıyor güncelleme ve kurulum testleri ve yeni özelliklerin test edilmesi. Hangi özelliklerin sürüme alınacağına ve hangi hataların sürüm için engelleyici olduğuna bu testler sonucu karar veriyorlar.

Sürüm testleri için oldukça detaylı bir test planına sahipler [3] hangi ön sürümün hangi adımlara kadar sorunsuz çalışması gerektiği belirlenmiş durumda. Bundan dolayı test ettikleri adımları daha detaylı biçimde test edebiliyorlar. Özetle beklentilerini ilk adımlarda düşük tutarak eldeki iş gücünü daha verimli değerlendirebiliyorlar.

Bu kategorideki test sonuçlarını pek renkli fakat hoş bir tablo üzerinden takip ediyorlar [4] . Burada dikkatimi çeken nokta ise her test adımının 1 kişi tarafından onaylanmasını test sonucu için yeterli görmeleri oldu.

Tabi bütün bu süreçler için hazır şablon belgelerden [5] yararlanıyorlar. Ayrıca her sürüm ile ilgili bilinen hataları ve çözümlerini listeledikleri [6] bir sayfaları mevcut.

Bu testler sırasında düzeltilen hataları NEEDSRETESTING olarak işaretleyerek [7] istekli testçiler tarafından yeniden test edilmesini sağlıyorlar.

Test araçları geliştirme bölümünde farklı kategorilerden araçlar üzerinde çalışıyorlar. Kurulum testleri için SNAKE [8] , python-bugzilla kütüphanesi [9] , ve Bodhi [10] bunlardan öne çıkanlar. Ayrıca test sistemini tam anlamı ile otomatik hale getirecek Breaker [11] aracının geliştirmesi de devam ediyor.

Bu noktada Breaker'ın üzerinde biraz daha durmakta fayda var. Breaker aslında RedHat tarafından kullanılan RHTS [12] aracının Fedora portu. Ancak aracı sadece port etmiyor aynı zamanda bazı özelliklerini ( örneğin test yazımı [13] gibi ) değiştiriyorlar. Test sonuçlarını Spike[14] adındaki bir arayüz ile kaydediyor.

Bittiğinde neredeyse tamamen otomasyona geçirilmiş ( alandığım kadarıyla GUI testleri içinde DogTail [15] entegrasyonu planlıyorlar ) bir test sistemine sahip olacaklar.

RHTS ve DogTail a biraz daha yakından bakacağım sanırım. Belki bu serinin ardından bir seri de otomatik test araçları için yazmak fena olamaz


[1] https://admin.fedoraproject.org/updates/F10/pending
[2] https://admin.fedoraproject.org/updates/metrics/?release=F10
[3] http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install
[4] http://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha
[5] http://fedoraproject.org/wiki/QA/TreeTestingTemplate
[6] http://fedoraproject.org/wiki/Bugs/Common
[7] http://feeds.feedburner.com/NeedsRetesting
[8] https://fedorahosted.org/snake/
[9] https://fedorahosted.org/python-bugzilla/
[10] https://fedorahosted.org/bodhi/
[11] http://fedoraproject.org/wiki/QA/Beaker
[12] https://testing.108.redhat.com/wiki/index.php/Rhts
[13] https://testing.108.redhat.com/wiki/index.php/Rhts/Docs/TestWriting
[14] http://developer.spikesource.com/wiki/index.php/Test_Results_Publication_Interface
[15] http://people.redhat.com/zcerza/dogtail/

12 Ocak 2009

Test Dünyasında Neler Oluyor ( Bölüm-2 Mandriva )

Serinin bu bölümünde dünyadaki en yaygın son kullanıcı dağıtımlarından birisi olan Mandriva'nın test ve bununla bağlantılı olarak kararlı depoya paket giriş süreçlerini inceleyeceğiz. Serinin bir önceki yazısını burada bulabilirsiniz.

Sanırım en doğrusu bir paketin kararlı depoya giriş sürecini [1] anlatarak başlamak olacak. Bir paket kararlı olduğuna emin olunan main/updates deposuna alınmak isteniyorsa, paketçi öncelikle bununla ilgili bugzilla raporu açar.

Bu rapor paketin neleri değiştirdiğini ve düzelttiğini anlatan advisory ile nasıl test edilmesi gerektiğini içerir ( örneğin: paketin kapattığı hatayı tekrar eden bir betik ve bunun dışındaki temel işlevleri nasıl test edileceğine dair bilgiler gibi). Hata kaydı kalite güvence takımına atanır( qateam ) ve güvenlik takımı da CC ye alınır ( secteam ). Bu işlemin ardından paket main/testing deposuna alınır.

Kalite-Güvence takımı pakete onay vermemişse ( daha iyi bir test-case yazılması veya uygulamanın kullanımına dair daha detaylı bilgi verilmesi bile olabilir bu ) paketin bakıcısı bu sorunları gidermek zorundadır.

Paketler ile ilgili hatalar tek bir e-posta adresinden giriliyor anladığım kadarıyla bunun amacı mesajlardan bütün takımın haberdar olması ve katkıda bulunabilmesi.

Kalite-Güvence takımdan onay alan paket için ilgili rapor güvenlik takımına atanır. Güvenlik takımı kaynak rpm dosyasını temiz bir sistemde yeniden inşa eder, paket ile ilgili advisory bültenini yayımlar [2] ( bu nokta ilginç aslında, konu güvenlikle ilgili olmasa dahi bütün paketler güvenlik takımından geçiyor ve düzeltme ile ilgili bülten yayımlanıyor ). Bu işlemlerin ardından paket main/updates deposuna alınarak hata kapatılır.

Anladığım kadarıyla güvenlik güncellemeleri ve kritik güncellemeler yukarıdaki politikanın dışında tutuluyor.

Bunun yanı sıra test otomasyonu (buna yarı-otomatik diyelim :) ) için web tabanlı testzilla[3] adlı bir araçtan faydalanıyorlar. Bu aracın temel işlevi testçinin donanım setine uygun olarak test edebileceği paketleri göstermek [4] ve bu paketler ile ilgili raporları girmesini sağlamak.

Asıl otomatik testler yalnız Paris'deki merkez ofiste yapılabiliyormuş. Burada PXE üzerinden başlatılan bilgisayarlara bu iş için özelleştirilen bir sürüm yükleniyor ağ üzerinden ve bu bilgisayarlarda önceden yazılmış test betikleri [5] çalıştırılıyor ve otomatik raporlar üretiliyor bugzillaya girilen.

Bunların yanı sıra bu prosedürleri ve betikleri wikiye aktarıyorlar [6] [7] belirli bir template [8] yapısı içinde.

Son olarak çekirdek testleri için ayrı bir bölüm ayırmışlar [9] ve çekirdek güncellemelerine ayrı bir özenle yaklaşıyorlar. Bu konuda da otomatik test için bir takım araçlardan haberdarlar ancak bunların ne kadarını kullandıklarına dair bir ipucu içermiyor test belgesi.


[1] http://wiki.mandriva.com/en/Policies/Support
[2] http://wiki.mandriva.com/en/2009.0_Errata
[3] http://wiki.mandriva.com/en/Development/Howto/Testzilla
[4] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/procedures/NVIDIA/procedure.html?revision=1.5&view=markup
[5] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/tests/pamd/valid-pamd-modules.test?revision=1.2&view=markup
[6] http://wiki.mandriva.com/en/Testing
[7] http://wiki.mandriva.com/en/Testing:Bind
[8] http://wiki.mandriva.com/en/Testing:Template
[9] http://wiki.mandriva.com/en/Development/Howto/Test_Update_Candidate_Kernels

6 Ocak 2009

Posted In: mandriva, pardus, test

Test Dünyasında Neler Oluyor… (Bölüm 1)

Bir süredir Pardus'un test işlerinden mesul-üm. Bu zaman zarfında, zaman zaman başka projelerin test işlerini nasıl yürüttüğüne göz atmış olsam da bütün projeleri kapsayan detaylı bir inceleme yapmak vardı aklımda. Test dünyasında işler nasıl yürüyor ? Başkalarından daha iyi olduğumuz yönler neler , nerelerde eksiklerimiz var ? Daha kaliteli bir dağıtım için neleri değiştirebiliriz ? gibi sorulara yanıt arayacağım. Derlediğim bilgilerde gözden kaçan, yanlış anladığım noktalar varsa düzeltmenizden memnun olurum.

Pardus

Daha önce biraz bahsetmiştim test süreçlerimizden. Bu vesile ile güncel değişiklikleri de katarak kısaca özetleyeyim.

Pardus'da Test süreçlerimiz 2 ana kategoriye ayrılıyor; Sürüm öncesi testler ve Sürüm içi testler. Bunlara dair detaylı bilgi wiki sayfamızda mevcut. Bir önceki yazının yazıldığı zamandan bu yana yapılan önemli bir değişiklik ise sürüm içi testleri artık gönüllülerimizle beraber yapıyor olmamız.

Bir sonraki adım da ise hata raporlarına bir onay mekanizması getirerek bu konudaki sorumluluğu da gönüllülerimizle paylaşmayı planlamaktayız.

OpenSuse

Görebildiğim kadarıyla yalnızca bir sonraki sürüme ilişkin test süreçleri mevcut. Kararlı sürüme girecek paketleri/yamaları ne şekilde test ediyorlar buna dair bir bilgiye rastlayamadım.

Geliştirme sürümlerini "Factory" namı ile anıyorlar. Bu sürüme dair yaklaşık 6 aylık yol haritaları belli. Ayrıca ara sürümler arasındaki önemli değişiklikleri de özet halinde yayımlıyorlar [1] Test sonuçlarını bugzilla üzerinden hata girerek raporluyorlar.

Hata takip sistemine nasıl hata girileceğine ilişkin oldukça detaylı dökümantasyona [2] [3] sahipler.

Bu noktaya kadar genel olarak bizden iyi durumdalar. Ama bu konular direkt olarak ilgilendirmiyor test süreçlerini.

Çok basit düzeyde temel test yönergeleri bulunuyor benim baktığım an itibariyle [4] . Bu konuda çok başarılı olduklarını söyleyemeyeceğim. Dağıtımı test etmeye yönelik temel süreçlerde bizim kadar detaylı bir planları yok. Ancak çok detaylı bir yol haritaları olduğu için değişen ve yeni gelen özellikleri test etmek konusunda oldukça detaylı bir çalışma yapmışlar.

İlginç gelen bir diğer nokta da mobil cihazlar ile olan senronizasyona ayrı bir bölüm ayırmışlar.

Son olarak da otomatik test araçları ile ilgili bir takım planları olduğu anlaşılıyor ki, bu araçları inceleyeceğim ayrı bir girdi yazmak niyetindeyim.

Edit: OpenSuse test süreçleri ile ilgili yeni bulduğum bir takım bilgileri eklemek istedim; Öncelikle Depo ve test politikalarını tanımlayan açık bir belge bulunmuyor. Uzun aramaların ardından kalite takımından Holger böyle bir belgeleri bulunmadığını yazdı.

Kalite takımı
demişken, 43 kişiden oluşan ( Novel çalışanı ) bir test takımları var. Açık olarak yazmıyor ama benim tahminim bu ekip sadece OpenSuse için değil Aynı zamanda SLES içinde çalışıyor.

Oldukça geniş bir araçseti kullanıyorlar testler için, liste aşağıda mevcut

• Bonnie.............................• Module Loading
• Buildcrunch...................• Newburn
• DBench...........................• Netperf
• FTPload..........................• NIC Bonding
• File System Stress.........• Process Stress
• LMbench .......................• Sched Stress
• LTP.................................• Reaim
• Memeater......................• Tiobench
• Memtester

Test otomasyonu için HAMSTA adlı bir araçları var ki aslında bu yerel test araçları için bir çeşit framework. Bunun yanı sıra test planlaması içinde Testopia'dan faydalanıyorlar. Ancak bu araç gereğinden fazla karmaşık göründü bana.

1 Eylül 2008

Posted In: pardus, test

Pardus Test Süreci’nin Dünü, Bugünü, Yarını

Pardus ekibine katıldığımdan beri pek fırsat bulamıyorum yazmaya. Oldukça yoğun ama bir o kadar da zevkli bir çalışma dönemi yaşıyoruz.

Sorumlusu olduğum Pardus test süreçlerinden bahsetmek istedim biraz. Hem süreçleri çekirdek ekip dışındakiler için biraz daha belirgin kılmak, hem de Pardus Test Takımına ve gelecekteki takım arkadaşlarımıza bir başlangıç noktası oluşturmak için.

Pardus ekibinin her üyesinde görebileceğiniz ortak bir özellik mükemmeliyet takıntısıdır. Bazen küçük bir düğmenin yeri ve işlevi için bile saatlerce tartışabiliyoruz. Ancak Pardus'la ilgili değerlendirmeleri okudukça harcadığımız bu zamanın karşılığını fazlası ile aldığımızı görüyoruz. Pardus Test Takımı da bu mükemmelleştirme sürecinin önemli bir parçası olmak üzere kuruldu.

Ne kadar yetenekli geliştiricilere sahip olursanız olun, tek başına sorunsuz çalışan parçalar bir araya gelince çalışmak konusunda sorun yaratabiliyorlar. Pardus Test Takımının görevi büyük yapbozu incelemek ve onu kusursuz hale getirmek.

Evvel zaman içinde, Pardus 1.0 sürümü öncesinde rootfs in çıkışı ile başlamış test takımı kurma fikri. O zamanki adıyla Resmi Pardus Test Sürecinin (RPTS) kordinasyonunu sevgili Erkan Tekman yürütüyormuş. Lakin zaman içinde iş yoğunluğunun arasında kaybolmuş gitmiş yeni sürümler çıkarken RPTS. Bu gün bu süreç daha geniş bir katılımla ve daha uzun soluklu olarak yeniden canlanıyor.

Yeni test sürecini planlarken önce diğer dağıtımların test süreçlerini inceledik. Kendi çalışma metoçlarımızı gözden geçirdik. Geçmişteki deneyimlerimize dönüp baktık. Sonuçta test süreçlerinin 2 ana bölüme ayrılmasına karar verdik.

Test takımımız şimdilik birinci bölümde bizlere yardımcı olacak ancak süreç ilerledik takımın içinde çıkacak istekli ve tecrübeli arkadaşlarla ikinci bölümü de bir ekip halinde yürütmeyi planlıyoruz.

Birinci Bölüm "Sürüm Öncesi Test Süreci"

Sürüm Öncesi Test Süreci alfa sürümünün çıkması ile başlayan ve kararlı sürüm ile sona eren yaklaşık 30 - 60 günlük bir süreçtir. Bu süreç de Alfa , Beta ve RC sürümleri çıktıkça, test takımımız kendileri için hazırlanan test kılavuzunun yardımıyla dağıtımın temel işlevlerini test edecek ve sonuçları test_takımı listesi aracılığı ile bizimle paylaşacaklar. Liste içinde istenilen bilgilerin tamamlanması ile gerekiyorsa hata takip sistemine aktarılacak hata bilgileri ve burada çözümlendikten sonra hatayı bildiren ve tekrarlayan takım üyelerince çözüm onaylanacak.

İkinci Bölüm "Düzenli Testler"

Bu test süreci yeni kararlı sürümün çıkması ile başlar ve sürüm resmi olarak desteklendiği sürece devam eder. Bu süreçte kendi içinde ikiye ayrılır. "Güncelleme Testleri" ve "İşlev Testi".

Bu süreç için öncelikle, test edilen kararlı sürüm ( örneğin Pardus-2007 ) ve o ana kadar çıkmış ara sürümlerin her birinin ( örneğin 2007.1 , 2007.2 , 2007.3 ) yeni kurulmuş birer versiyonuna sahip olmamız gerekir. Her bir testin ardından tekrar bu temiz kurulumlara ihtiyaç duyacağımızdan bu sürümleri sanal görüntü olarak kurmak ( misal VirtualBox ile ;) ) sağlık ve de sıhhat açısından faydalıdır. Bu sanal görüntüleri güncelleme testlerinde kullanacağız.

Ayrıca her güncelleme sonrasında kararlı depodan güncellediğimiz düzenli güncellenen bir sanal imaja da ihtiyaç vardır.

Süreç genel hatları ile şöyle işler; Test sorumlusu test deposunda bekleyen paketler için bir onay süreci başlatır. Geliştiriciler tarafından onaylanan paketler o anki kararlı depo ve onay alan yeni paketlerden oluşan bir geçici depoya aktarılırlar. Temiz kurulmuş sürümlere bu deponun adresi verilerek sürümler güncellenir. Her güncellenmiş sürüm yeniden başlatılarak temel sistemlerin sağlıklı işleyip işlemediği kontrol edilir. Ardından revdep-rebuild komutu ile ters bağımlılıklardaki kırık paylaşımlı kütüphane dosyalarının varlığı denetlenir.

İşlev testi içinse, kararlı depo ile eş zamanlı güncellediğimiz imaj, test için geçici depodan güncellenir ve güncellenen her bir program tek tek test edilir.

Testçinin bütün program ve kütüphaneleri bütün özellikleri ile test etmesi bilgi, tecrübe ve zaman açısından mümkün görülmediği için test edilecek olan paketler 4 ana kategoriye ayrılmıştır. Kategorizasyon işlemi halen devam etmekte olup yeterince olgunlaşınca wikiye aktarılacak. Bu kategoriler; Detaylı biçimde test edilecek paketler ( ki bunların nasıl test edileceği ayrıntılı olarak belgelenmiştir ) , Standart biçimde test edilecek paketler ( kurulum ve temel çalışma denetimi yapılır ) , Yalnız kurulum testine tabi tutulacak paketler ve Multimedya paketleridir ( Multimedya paketlerininde nasıl test edileceği detaylı olarak belgelenmiştir ).

Bu süreçler Pardus'un dünyada ve Türkiye'de hak ettiği yere gelmesinde önemli rol oynarken bizlere de test takımımızın içinden yeni dostlar ve yeni geliştiriciler kazandıracak. Özgürlük İçin...

5 Nisan 2008

Posted In: pardus, test

Çarşı OOXML ‘e KARŞI !

Uzun zamandır bir şeyler karalamadığımı düşünecek olursak aslında anlatılacak çok şey var. Ancak daha önemli konular var. Camia yı takip edenler bir süredir OOXML ve TSE'nin bu konudaki tavrı konusundaki log girdilerini ve e-postaları görmüşlerdir. Bende bu girdilerden ve postalardan yararlanarak bilgi edinme yasası gereği cevaplanmak üzere bir takım sorular yönelttim TSE ye. Gelen cevapları yayınlayacağım. Bu şekilde yeterince fazla kişi soru sorar ise en azından dikkati çekilebilir TSE'nin diye düşünüyorum. Gönderdiğim bilgi edinme isteğinin tam metni ise aşağıda;

Sayın Yetkili,

Elektronik ortamdaki dokümantasyon için açık standartların belirlenmesi konusundaki sorunların çözümü için şubatta Cenevre'de yapılacak olan "Ballot Çözüm Toplantısı" (Ballot Resolution Meeting) na ve TSE nin bu toplantıda ne şekilde tavır alacağına ilişkin bir takım sorularım olacak. 4982 Sayılı Bilgi Edinme Kanunu uyarınca bu soruların cevaplanmasını arz ederim.

1- Cenevre'deki Ballot Çözüm Toplantısı'nda (DIS 29500) TSE'yi kim temsil edecek?

2- Toplantıya ülkemiz adına katılacak olan delegeler, Microsoft'tan yeterince bağımsız mı?

3- TSE'nin sorumlu komitesi 3500 çözüm önerisi veya hepsi değilse bile sadece gönderdikleri ulusal açıklamalar üzerinde çalışıyor mu?

4- TSE temsilcisinin Micrsoft'un önerdiği standart olan OOXML lehine oy kullanacağı yönündeki bilgiler doğru mudur ? ( Lütfen ekdeki apora bakınız )

5- Eğer 4. sorunun cevabı evet ise TSE temsilcileri aşağıdaki durumların farkında mıdır ? Ve bu konuların varlığına rağmen Microsoft'un görüşleri lehinde oy kullanmayı halen düşünmekte midir ?

a- Microsoft'un sunduğu belgede OOXML sistemi içersinde yer alan bir çok
maddenin sadece "isimleri" belirtilmiş ama bu maddeler tanımlanmamıştır.
Microsoft bu bilgeleri kendine saklamakta ve kesin bir tanım vermeyi
reddetmektedir.

b- Bir başka durum ise Microsoft'un gönderme yaptığı standartları açık olarak
bildirmemesi. Örneğin bir karakter kümesinin birden fazla sürümü olduğu
durumda Microsoft bu karakter kümesinin hangi sürümüne gönderme yaptığını
bildirmemiştir. Bu durumda A kişisi ürettiği bir belgeyi iki farklı
arkadaşına yolladığı zaman bu iki kişi aynı belgeyi sadece farklı editörler
kullandıkları için özgün halinden başka bir şekilde görebilirler.

c-Microsoft OOXML standardında kullanacağını beyan ettiği bazı alt sistemleri
kendi patenti altında barındırmaktadır. Bu durumun en vahim sonucu Microsoft
patentlerinin kullanım hakkına sahip olmadan OOXML formatlı bir belgenin
açılmasının mümkün olmamasıdır. Microsoft bu belgede bu teliflerin kamunun
kullanımına açılıp açılmayacağı konusunda herhangi bir açıklamada
bulunmamıştır.

d- Microsoft OOXML ile ne yazık ki plartform bağımsız bir standart yaratmaktan
çok uzakta bir noktadadır. Bu haliyle OOXML ancak Windows ortamında ve ancak
Office programı aracılığı ile tam ve verimli olarak kullanılabilecek gibi
görünmekte. Diğer editörler (örneğin OpenOffice) OOXML formatlı belgeleri ya
hiç açamayacak ya da açabilseler bile özgün belgenin görünüm ve içeriğinden
çok farklı ve sorunlu bir şekilde görüntüleme imkanı sunacaktır.

11 Aralık 2007

Mehmet

Olur ya, bir çatışmada ölürsem,
Arkamdan yas tutmayın.

Bırakın toprağımda rahat içinde yatayım.
Bedenimden komandomu çıkarmayın,
Onlar benim onurumdur,
Ölünce kefenim olacak...

Başımdan mavi beremi çıkarmayın,
O benim şanım,şerefim olacak...

Ayağımdan botlarımı çıkarmayın,
Onlar nice yollar aşacak,
Şehit olursam Sırat köprüsünden geçecek...

Elimden tüfeğimi almayın,
O benim mezarıma sembol olacak...

Yaramın kanını silmeyin,
Ahirette hesabı sorulacak...

Göğsümden kör kurşunu çıkarmayın,
O benim madalyam olacak...


* Bu şiir, Hakkari - Çukurca - Üzümlü Jandarma Sınır Karakolu'nda görevliyken 12 Aralık 1993 günü saat 21.00 sıralarında bölücü eşkiya ile yapılan silahlı çatışmada şehit düşen Jandarma Komando Onbaşı Zekeriya Gülyaman'ın şahsi eşyaları içerisinden çıkmıştır.

10 Ekim 2007

Gençliğe Hitabe

Ey Türk gençliği! Birinci vazifen, Türk istiklâlini, Türk cumhuriyetini, ilelebet, muhafaza ve müdafaa etmektir.


Mevcudiyetinin ve istikbalinin yegâne temeli budur. Bu temel, senin, en kıymetli hazinendir. Istikbalde dahi, seni bu hazineden mahrum etmek isteyecek, dahilî ve haricî bedhahların olacaktır. Bir gün, İstiklâl ve cumhuriyeti müdafaa mecburiyetine düşersen, vazifeye atılmak için, içinde bulunacağın vaziyetln imkân ve şerâitini düşünmeyeceksin! Bu imkân ve şerâit, çok nâmüsait bir mahiyette tezahür edebilir. İstiklâl ve cumhuriyetine kastedecek düşmanlar, bütün dünyada emsali görülmemiş bir galibiyetin mümessili olabilirler. Cebren ve hile ile aziz vatanin, bütün kaleleri zaptedilmiş, bütün tersanelerine girilmiş, bütün ordulari dagitilmiş ve memleketin her köşesi bilfiil işgal edilmiş olabilir. Bütün bu şerâitten daha elîm ve daha vahim olmak üzere, memleketin dahilinde, iktidara sahip olanlar gaflet ve dalâlet ve hattâ hiyanet içinde bulunabilirler. Hattâ bu iktidar sahipleri şahsî menfaatlerini, müstevlilerin siyasi emelleriyle tevhit edebilirler. Millet, fakr ü zaruret içinde harap ve bîtap düşmüş olabilir.


Ey Türk istikbalinin evlâdı! İşte, bu ahval ve şerâit içinde dahi, vazifen; Türk istiklâl ve cumhuriyetini kurtarmaktır! Muhtaç oldugun kudret, damarlarındaki asil kanda, mevcuttur!

K. ATATÜRK
20 Ekim 1927

9 Ekim 2007

Posted In: istiklal

Hayali Yazılımcı

Başlıkta gördüğünüz deyim henüz literatüre girmedi. Ama yakında girecektir zannımca ben de isim babası olayım istedim. Sebebini buradan okursunuz.

Not: Bu arada çeşitli mecralarda "devlet işletim sistemi geliştireceğine o parayı yazılımcılara teşvik olarak verse memleket ihya olurdu" diye yırtınan bir takım lamer bozmaları ile yardakçılarının gözü aydın. Buyrun bakalım alın teşviklerinizi de ne geliştirecekmişsiniz bizler de bir görelim.

7 Ekim 2007

Posted In: kına, teşvik, yazılım

Bağlantısız Haber Televizyonu

Odatv.com adlı haber televizyonu ( haber sitesi değil ) yayına başladı.Soner Yalçın ve Cüneyt Özdemir tarafından kurulan televizyonun bilindiği kadarı ile hiçbir medya grubu ile direkt bağlantısı yok. Televizyondan ilginç bir haberde aşağıda.

Bu görüntü Irak işgaline katılan İngiliz askerlerinin kamerasından yansıyor. Kendi jeeplerinin içinde arkadan gelen arabalara rastgele ateş ediyorlar. Arkadan gelen arabaları vurduklarında seviniyor, vuramadıklarında üzülüyorlar.

4 Ekim 2007

Posted In: internet, odatv.com

WP Twitter Auto Publish Powered By : XYZScripts.com