Özgür Web Teknolojileri Günleri 2013

Geçen hafta sonu Yeditepe Üniversitesi'nde Özgür Web Teknolojileri Günleri etkinliği yapıldı. Çömü'den Necdet hoca ve Aybüke ile katıldık. Bu yıl etkinlik sınav zamanına denk geldiğinden bizim üniversiteden sadece Aybüke ve ben katılabildik. 1. ve 3. sınıfların sınavları hafta sonuna kadar sürdü. Tabi Çömü'lü mezunlardan da bir sürü gelen vardı :)

Bu yıl genel konu "Ölçeklenebilirlik" üzerineydi. Aybüke ve ben aynı zamanda konuşmacı olarak katılmıştık. Ben geçen dönem Kaan ile çalıştığım projeden, Nagios, Couchbase, eklenti yazımı gibi konulardan bahsettim. Aybüke yazın stajı Kaan'ın yanında yaptı. Staj sırasında yazdığı haproxy-tools'dan bahsetti.

Bu yaptığım 2. konuşma olması ile birlikte bu sefer daha fazla heyecanlandım. İlki Muğla'daydı. Orada genelde dinleyiciler öğrencilerden oluştuğu için daha rahattım, çünkü ben de öğrenciyim. Sunum öncesi Doruk Fişek tavsiyelerde bulundu ama sunumu izlediğimde fark ettim ki, pek uygulamamışım :) Bir sonraki sunumumda muhtemelen daha rahat konuşurum diye düşünüyorum.

Dinlediğim sunumlardan en çok Gökhan'ın konuşmasını beğendim. Sunum başlığı "Ölçeklenebilir Web Mimarisi"ydi. Gökhan, Çömü'den mezun. Ben 1. sınıftayken, o 4. sınıftı ve ÇOMaK projesinde çalışıyordu. Sunumda oldukça güzel ve eğlenceli anlattı.

Etkinliğin 2. günü mezun olan üst dönemlerle toplanıp, görüşme fırsatım oldu. Ben çalışma hayatıyla ilgili merak ettiklerimi sordum. Mezuniyet sonrası için düşüncelerim biraz değişti. Aslında bu dönem başında Necdet hoca mezuniyet sonrası için aynı şeyleri önermişti.

Son olarak etkinlik hediyesi tişörtü çok beğendim :)

Linux Çekirdeğine Nasıl Katkı Verilir?

Gnome'un düzenlemiş olduğu Outreach for Women etkinliğine başvuru süreci 11 Kasım'da bitiyor. Ben bu süreçte Linux Kernel için hazırlandım. Geçen yıl Gnome'un kendi araçlarına başvuruyordum ama sürekli bir şeyler derlemek, kütüphane sürümlerini uyuşturmaya çalışmak bir miktar sıkıcı olabiliyor. Bunun için jhbuild ya da Fedora'nın bir sonraki, henüz çıkmamış sürümünü kullanmak tavsiye ediliyor :) Çünkü katkı vereceğimiz Gnome aracının depodaki son hali üzerine değişiklik yapmalıyız. Çekirdek üzerinde çalışmanın nasıl olduğunu bilmediğimden bu sefer çekirdeğe başvurmaya karar verdim.

Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen bir kaç kitap var. Öncelikle örnek olarak ethernet kodu içine printk("..") ile bir şeyler yazdırıp, çıktısını dmesg logunda görmek var. Burada Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. Temel olarak yama göndermeye kernel.org'dan aldığımız çekirdek kodları dizini içerisindeki drivers/staging'den başlayabiliriz. Buradaki kodların yazılış biçimini düzeltmeyle işe başlayabiliriz. Greg'de linkini verdiğim sunumunda bundan bahsetmiş. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karma düzeltmeler de yapabiliriz. Bir de yama gönderirken e-posta konu satırına uyarı çıktısının tam halini yazmamız gerekiyor. Kendimiz uyarıyı yorumlayıp "bu yama bunu düzeltiyor" şeklinde yazdıklarımız genelde kabul edilmeyebiliyor. Bu yüzden tekrar göndermemiz gerekiyor.

Opw Kernel'a başvurmak için bu temel yamalardan göndermek yeterli. Hatta bu yılki Opw projelerinden birisi de kodlama biçimi düzeltme ve Todo dosyalarındaki eksikleri kapatma. Todo dosyalarındaki eksikleri kapatmak biraz daha alt seviye, aslında baya bir alt seviye :). Çünkü yapılması istenenler de o kadar açık belirtilmemiş dosyada. Ben de çekirdek uyarı mesajlarını analiz etme ve iyileştirme projesine başvurdum.

Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz. Bir de kodlar içerisinde yer alan Fixme etiketlerinden yararlanarak katkı vermek de yapabileceğimiz seçeneklerden birisi. Katkı verirken zorlanabileceğimiz yanlardan birisi, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca göndermek gerekebiliyor. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği var. Zaten kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.

Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz. Bu düzeltmeleri yapmak için koddaki fonksiyonları okuyup, çağırılma sıralarını kontrol etmek, kzallac, kmalloc, volatile gibi tiplere, tip dönüşümlerine bakmak gerekli. Çeşitli tiplerin ne olduğunu öğrenmek için burayı okumak faydalı olabilir.

Coccinelle aracını ise ben henüz kullanmadım. Ancak önümüzdeki günlerde onu da denemeyi düşünüyorum. Bir de daha karmaşık hataları çözebilmek için bir kitap bulup okumayı düşünüyorum.

Opw ekibi projede çalışmak için kişi seçerken genelde öğrenci olmamasını tercih ediyor :( . Okul dönemi içerisinde olan bir öğrenci seçmektense herhangi bir işte çalışmayan birisini seçmenin daha verimli olacağı düşüncesindeler. Bu yüzden öğrencilerin Opw yaz dönemine başvurunca seçilme ihtimali daha yüksek. Çünkü proje sürecinde bir işin var mı sorusuna, sınav haftalarını yazmaktansa hiç işim yok yazmak, şansımızı artıran bir etken. Eğer ben de bu dönem kabul edilmezsem, yaz dönemi tekrar başvuracağım.

Çekirdeğe Katkı Sürecinde Git Kullanımı

Git uzaktan birlikte çalışmak için oldukça yetenekli bir araç. Bu dönem Linux Kernel'a katkı verirken git'in daha fazla özelliğini kullanmam gerekti. Çünkü çok fazla kişinin sürekli aynı dosyalar üzerinde değişiklik yapıyor olması durumunda daha gelişmiş bir biçimde sürüm takip sistemi kullanmak gerekiyor.

git-send-mail

Tarayıcı üzerinden yamayı mail gövdesine kopyaladığımızda girintilerde kaymalar, satırlarda kaymalar meydana gelebilir. Bunun için yama dosyasını e-postada ek olarak göndermeliyiz, ya da git-send-mail ile göndermeliyiz. git-send-mail için temel bir kaç ayar gerekli, bu ayarları her seferinde yeniden girmemek için yapılandırma dosyasına yazabiliriz. Ev dizinimizdeki .gitconfig dosyası için gerekli olan ayarları ben buradan örnek alarak ayarlamıştım

git-rebase

Yerelimdeki Linux Kernel deposuyla uzaktaki depoyu senkron tutmam gerekti. Opw Kernel sayfasında bahsedildiği gibi depomda değişiklikler yaptım. Bunun için öncelikle "git remote add" diyerek "staging" adı altında depoyu izlediğim depolar arasına ekledim. Bu şekilde depo ekleyip, deponun istediğimiz dallarını çekebiliriz. Daha sonra "git rebase staging/staging-next" ile rebase işlemini tamamlamış oluyoruz.

Aslında burada aklıma takılan "merge" kullanarak da bir çok şeyi halledemez miyiz, olmuştu. Ancak merge kullandığımızda aynı depo üzerinde çalışan herkesin, her şeyi kusursuz yapmış olmasını beklemek gerekir. Eğer küçük bir ekiple çalışıyorsak "merge" yeterli oluyor. 

git-rebase ile aynı zamanda commit tarihimizi değiştirebiliriz, eskiden yaptığımız bir committeki değişiklikleri düzenleyebiliriz. Bunun için "git rebase --interacative commit_id" diyoruz. Bu şekilde rebase etme sürecini başlatabiliriz.

Eğer son yaptığımız committe bir değişiklik yapacaksak "git commit --amend" olarak kullanabiliriz, ancak son committen daha eski commitler üzerinde oynamak için "git rebase --interactive" kullanmalıyız. Daha sonra karşımıza çıkan editörde commit mesajını değiştirmek istediğimiz commitin başındaki "pick" ifadesini "edit" olarak değiştirmeliyiz. Daha sonra "git commit --amend" kullanıp, commit mesajını değiştirmeye başlayabiliriz. Son olarak "git rebase --continue" ile commit mesajı değiştirme sürecini bitirmiş oluruz.

Üzerinde oynadığım büyük bir dosyada 9 tane commit yapmıştım ve bu commitlerde yaptığım değişikliklerin arasından 4-5 tanesini düzeltmem gerekti. Son değişikliklerde öncekilere bağlı olduğundan, dosyanın son hali üzerinden tekrar düzeltip göndersem, dosyanın depodaki orjinali bu değil diye geliştiriciler kabul etmiyorlar. Bu durumda eğer 5. commit değişmeliyse, dosyanın 5. committeki hali üzerinden düzeltmek gerekli. Ya da tüm yama serisini baştan hazırlamalıyız ki, bu zorlaştıran bir iş.

Bu yüzden git rebase'i kullanıp, edit şeklinde committi seçiyoruz. Daha sonra değişiklikleri yapıp "git add üzerinde_çalıştığımız_dosya" ve "git rebase --continue" şeklinde bu işlemi bitirebiliriz. "--continue" parametresini rebase ile yapacağımız değişiklikler bittikten sonra kullanmalıyız.

edit, dışında bir de "squash" ile yaptığımız commitleri birleştirebiliriz. Eğer altı kere değişiklik yapıp bunları hepsini ayrı ayrı commitlediysek format-patch ile oluşturacağımız yamalarda altı parçadan oluşacak. Eğer bunların hepsini tek bir commit mesajı altında birleştirmek istiyorsak "pick" yerine "squash" yazarak bir kaç commit mesajını bir mesajda birleştirmeyi sağlayabiliriz.