Re: [Gelistirici] 2011 toolchain vs.
On Monday 09 August 2010 20:47:15 Onur Küçük wrote: Ayrıca paketlerin bölünme politikası ve svn de geliştirmenin nasıl süreceği (devel e mi komit edeceğiz, stable a taşıma mı yapacağız vs.) gibi konularda tanımlanmamış kısımlar varsa adını yazılı olarak koymamız lazım. Bölünme politikası ile ilgili birtakım bilgiler isimlendirme belgesinde var. Depoda konuşulup da orada yazmayan şeyler olabilir. Sanırım tek bir başlık dosyası için bile -devel paketi çıkaracağımız konusu bunlardan biri. Commit'leri devel'e yapıyoruz. devel ve stable ayrı ayrı farmlara sahip olacağı için şimdiden stable'a kopyalamaya gerek yok. Muhtemelen beta sonrası stable'ı açarız. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] iş takip aracı ve gelişmeler
Selamlar, Yaklaşık 3 hafta önce Redmine'ı kurup, ilgilenebileceğimi söylemiştim. Redmine'ı kurdum, dışarıdan http://tracker.pardus.org.tr adresi ile erişilebilir durumda. Proje içerisinde kullanacağımız özelliklere bakıldığında Redmine yeni sürümü ile kullanılmak için uygun gibi görünüyor. Ayrıca geçen hafta içerisinde olan bir gelişmeden daha bahsetmek istiyorum. Tüm projelerimizi iyi bir şekilde yürütebilmek adına TUSSİDE'de (Türkiye Sanayi Sevk ve İdare Enstitüsü) 2 günlük proje yönetimi eğitimi aldık. Bu eğitimler teorik ve pratik olmak üzere iki ana bölüm içeriyordu. Pratik eğitimlerimizi Hakan Uygun ile birlikte Redmine üzerinde gerçekleştirdik. 2011 projesi ve diğer teknolojiler (pisi, yalı, kaptan, *-manager ailesi) için nasıl bir proje yönetimi izleyebileceğimizi öğrendik, konuştuk ve tartıştık. Bu eğitimde edinilen bazı bilgilerden kısaca bahsetmek istiyorum: 1. Yaptığımız sürümlerin (2009, 2011, kurumsal vs) ve diğer teknolojilerin kendi başına birer proje olarak düşünülmesinin, proje yönetimi açısından daha iyi olabileceği ortaya çıktı. 2. Redmine ve benzeri uygulamaların iş takibi için var olduğunu ve yapılacakların bu araca girilmeden önce proje planlaması (zamanlama, önceliklendirme) yapılmasının gerekli olduğunu öğrendik. (Bilgilendirme: ) 2011 projesinin planlanması ile ilgilenmeye başladık 1 veya 2 hafta içerisinde bunu tamamlayıp listede paylaşmayı düşünüyoruz.) 3. Birbiri ile ilişki içerisinde olan projelerin nasıl yürütüleceği hakkında bilgi edindik. Örnek vermek gerekirse, birbiriyle ilişkili olan 2011 projesi ve diğer teknolojiler baz alındığında 2011'in kod dondurma tarihi, x teknolojisinin y versiyonunun özelliklerini tamamlamak için de son tarih olacaktır. Bu durum da birbiri ile ilişkili projelerin tasklarının 2011'de dummy bir task'a bağımlı hale getirilip, bu dummy task altında tutulmasıyla gerçekleştirilebilir. Misal, x projesinin a, b, c tasklarını 2011 projesinde bulunan x projesi y versionu bitişi adındaki dummy task'a bağımlı hale getirmek.. Ne dersiniz? 4. iş takibi araçlarının genellikle gündelik yapılacak işler için çok uygun olmadığını öğrendik. Bu durum için de paket yapma, onaylama (Review, ACK-NACK) gibi süreçlerin iş takip sisteminde yer alıp almayacağı Redmine'a geçişimiz sırasında hep beraber kararlaştıracağız. Böyleyken böyle 2011 ile birlikte Redmine'da işlerimizi takip edebileceğimiz bir araca da kavuşmuş olacağız, hayırlısı olsun :) Bu arada dün bir 2011 toplantısı gerçekleştirdik, bunun ile ilgili toplantı notlarını ve Redmine ile 2011'de yapılabilecekleri, Gökçen mail olarak iletecek :) Herkese kolaylıklar, -- Semen Cirit TUBITAK/UEKAE - Pardus GNU/Linux http://www.pardus.org.tr/eng ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Java Paketleme Kurallari
On Monday 09 August 2010 00:39:22 S.Çağlar Onur wrote: Eger paketleri kaynaklarindan derlemeyecek, yanlarinda tasidiklari statik bagimliliklari atmayacak ve bunlar yerine paketlenmis ve sisteme yayilmis kutuphaneleri kullanmasini saglamayacaksan bence bu ise girismenin hic bir anlami yok. Soyledigimin kolay bir is olmadiginin farkindayim ama zaten kolay bir is olsaydi da simdiye kadar 100 kere cozulmus olurdu diye dusunuyorum. Sadece o paketler depoda olsun/birilerine gerekiyor diye hareket etmenin saglikli oldugunu da dusunmuyorum. Her kurdugu ornegin tomcat'in yaninda gelen apache-logHEDE'nin 20 farkli surumunu diskinde tutmaktan, classpath'ler falan ile ugrasmaktan, X surumu ile loglar cok guzel olurken Y surumu ile olmuyormus , dur o zaman suradaki jar'lari suraya kopyalayayim hamleleri yapmaktan cekinmiyorsa ve biz bunlari cozmek icin kuracak/kullanacak kullaniciya herhangi bir arti sunmayacak/sunamayacaksak o kullanici gidip n bin tane jar dosyasindan olusmus ve unzip edildigi yerde calismaya baslayan ornegin tomcat'i mesela eliyle de kurabilir. +1 Paketlemeye (kaynaktan derlenebilecek şekilde) uygun olanları depoya alabiliriz. Her kitaplığın farklı minör sürümleri depoda yer almasın. Mümkün olduğunca son sürümleri alalım. Bu sürümlerden memnun olmayan eliyle de kurabilir. Minör sürümlerde API kırılıyorsa kaynaktan derleneceği için bu tür durumlarda uygulamalar yamalanabilir. Zor iş :/ ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] iş takip aracı ve gelişmeler
2010/8/10 Semen Cirit sci...@pardus.org.tr: Selamlar, (Bilgilendirme: ) 2011 projesinin planlanması ile ilgilenmeye başladık 1 veya 2 hafta içerisinde bunu tamamlayıp listede paylaşmayı düşünüyoruz.) Bunun için kısa bir açıklama yapma gereği duydum, çıkarılacak olan bu plan aslında genel olarak tüm sürüm projelerinde kullanılacak bir ana taslak niteliğinde. Bu plan 2011 ile birlikte uygulamaya geçebilir şeklinde düşündüğüm için bu şekilde yazmıştım :) -- Semen Cirit TUBITAK/UEKAE - Pardus GNU/Linux http://www.pardus.org.tr/eng ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Java Paketleme Kurallari
Merhaba, Listeye ulaşıp ulaşmadığımdan emin olamadığım için tekrar yolluyorum. İkinci kez alanlardan özür diliyorum... Öncelikle genel olarak fikrimi söyleyeyim. Java'nın yapısı nedeniyle çoğu zaman sistemde aynı anda farklı JVM'den tutunda aynı uygulamanın farklı sürümlerinin bir arada çalışması gerekiyor. Dolayısı ile uygulamaların ihtiyaç duyduğu jarların ayrı ayrı paketlenip sistem üzerinde takip edilmesi çok anlalı olmuyor. Bu paketlerin güncelleme ile ilgili kolaylıklar sunmasına rağmen aynı zamanda otomatik güncellemelerin çeşitli uygulamlarda sorun çıkarabileceği gerçeği var. Minör bir sürüm değişikliği bir uygulamanın çalışmamasına neden olabiliyor. Bu nedenle uygulama sunucular içinde koşan ear paketleri çoğu zaman ihtiyaç duyduğu bütün kütüphaneleri de içerisinde barındırır. Örnek vermek gerekirse aynı uygulama sunucu içerisinde koşan ve benzer teknolojileri kullanan iki farklı uygulama aynı kütüphanenin farklı sürümleri ile çalışıyor olabiliyor. Bu noktada önerim her uygulamanın kendi ihtiyaç duyduğu bütün kütüphanelerle bir arada paketlenmesidir. Örneğin Jboss 4 ile Jboss 5 aynı kütüphaneleri kullanıyor olsa bile kendi içerisinde bütünlükle paketlenmeliler. Dez avantajı diskte fazla yer kaplaması olmakla birlikte uygulamanın bütünlüğü açısından önemli. Ayrıca Java uygulama sunucuların, jvm'lerin v.s. paketlenmesi sırasında orjinal dosya ağacını dağıtmanın da kullanıclar açısından sorun yaratabileceğini düşünüyorum. Log v.s. için symbolic linkler konuyor olabilir ama onun ötesinde uygulamanın orjinal dokümantasyonlarını takip edecek bir kullanıcı için işler çok zorlaşıyor... - selim ok seli...@gmail.com wrote: Merhabalar, - Kaynaktan mi derleyelim, yoksa dogrudan ikilileri mi? (Önceligimiz kaynaktan derleme, fakat cok cok zor olursa ikili kabulümüz! gibi arada kalmis cevaplar da verilebilir bu soruya.) - Kitapliklari derleyelim mi? Bence uygulamanın orjinal derleme sistemini çok bozmadan mümkün olduğunca kaynaktan derlemeliyiz. Örneğin Jboss'u derlemeye kalktığımızda kendi derleme sistemi gereken kütüphanleri orjinal paket içerisinden derlenmiş olarak alıp derliyor. Aksi halde daha önce bahsettiğim kütüphane sürüleri ile ilgili sorunlar çıkabiliyor. Örneğin Jboss üzerinde bir derleme yapıyoruz fakat kullanılan bir kütüphanenin en güncel sürümü bu derleme içerisinde kullanılmamış olabilir. O kütüphanenin güncel sürümünü kullandığımızda büyük ihtimal Jboss'un derleme ve daha kötüsü çalışma zamanı problemleriyle uğraşmak zorunda kalırız. - Ayni uygulamanin birden fazla sürümünü depoya ekleyebilir miyiz? Bkz. jre5-jre6, tomcat5, tomcat6, jboss4-jboss6 vs. Bence kesinlikle eklenmesi gerekiyor. Aynı sistem üzerinde farklı JVM'ler üzerinde farklı uygulama sunucu sürüleri üzerinde koşan uygulamalar olabiliyor. Sismenin kaynak kullanım problemleri sistei yöneten kişinin sorumluluğunda diye düşünüyorum... Burada sistem yöenticisi bir zahmet diğer sürümleri kendi kursun deniyor olabilir ama özellikle JVM konusunda farklı sürüleri kesinlikle desteklemeliyiz diye düşünüyorum... - Farkli java sanal makine gerceklemelerini paketleyelim mi? (icedtea vs.) Yani is gücünü buldugumuzu var sayiyorum, politik olarak mümkün mü? Bence bu da mümkün olsa iyi olur. Özellikle önümüzdeki dönemde jdk7 ile birlikte Sun/Oracle jvm'i ve OpenJDK ve icedtea kullanıcı tercihine göre kurulması ciddi bir ihtiyaç olacaktır. - Dosya türlerine göre dizin secimimiz nasil olmali. (birlikte gelen jar paketleri nereye gitmeli, genel olarak opt yada usr altina kurulmali vs.) Bence jvm ve uygulama sunucuları dağıtmamalıyız. Opt altında yaşıyor olabilirler. Dokümanlar ve Loglar için symlink konuyor olabilir. Hatta jvm örnekleri v.s. ayrıca paketleniyor olabilir ama mümkünse orjinal dokümanlarda belirtilen yerlerde bulunuyor olsalar iyi olur. Hakan Uygun -- Uygun Teknoloji Bil.Hiz.Tic.Ltd.Şti. web: www.uygunteknoloji.com tel: +90 212 2589780 gsm: +90 533 2761692 ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Java Paketleme Kurallari
Merhaba; 2010/8/10 Hakan Uygun hakan.uy...@uygunteknoloji.com.tr Merhaba, Listeye ulaşıp ulaşmadığımdan emin olamadığım için tekrar yolluyorum. İkinci kez alanlardan özür diliyorum... Öncelikle genel olarak fikrimi söyleyeyim. Java'nın yapısı nedeniyle çoğu zaman sistemde aynı anda farklı JVM'den tutunda aynı uygulamanın farklı sürümlerinin bir arada çalışması gerekiyor. Dolayısı ile uygulamaların ihtiyaç duyduğu jarların ayrı ayrı paketlenip sistem üzerinde takip edilmesi çok anlalı olmuyor. Bu paketlerin güncelleme ile ilgili kolaylıklar sunmasına rağmen aynı zamanda otomatik güncellemelerin çeşitli uygulamlarda sorun çıkarabileceği gerçeği var. Minör bir sürüm değişikliği bir uygulamanın çalışmamasına neden olabiliyor. Bu nedenle uygulama sunucular içinde koşan ear paketleri çoğu zaman ihtiyaç duyduğu bütün kütüphaneleri de içerisinde barındırır. Örnek vermek gerekirse aynı uygulama sunucu içerisinde koşan ve benzer teknolojileri kullanan iki farklı uygulama aynı kütüphanenin farklı sürümleri ile çalışıyor olabiliyor. Bu noktada önerim her uygulamanın kendi ihtiyaç duyduğu bütün kütüphanelerle bir arada paketlenmesidir. Örneğin Jboss 4 ile Jboss 5 aynı kütüphaneleri kullanıyor olsa bile kendi içerisinde bütünlükle paketlenmeliler. Dez avantajı diskte fazla yer kaplaması olmakla birlikte uygulamanın bütünlüğü açısından önemli. Sanırım 2008 depolarında bu şekilde irili ufaklı jar paketleri bulunuyordu. Daha sonra bunlar temizlendi. Java dünyası için gstreamer veya libtorrent kütüphanesi gibi liblerin ayrılmasına gerek yok. Genelde java uygulamaları ihtiyaç duydukları kütüphane versiyonlarını kendi jarlarında barındırıyorlar. Ayrıca Java uygulama sunucuların, jvm'lerin v.s. paketlenmesi sırasında orjinal dosya ağacını dağıtmanın da kullanıclar açısından sorun yaratabileceğini düşünüyorum. Log v.s. için symbolic linkler konuyor olabilir ama onun ötesinde uygulamanın orjinal dokümantasyonlarını takip edecek bir kullanıcı için işler çok zorlaşıyor... - selim ok seli...@gmail.com wrote: Merhabalar, - Kaynaktan mi derleyelim, yoksa dogrudan ikilileri mi? (Önceligimiz kaynaktan derleme, fakat cok cok zor olursa ikili kabulümüz! gibi arada kalmis cevaplar da verilebilir bu soruya.) - Kitapliklari derleyelim mi? Bence uygulamanın orjinal derleme sistemini çok bozmadan mümkün olduğunca kaynaktan derlemeliyiz. Örneğin Jboss'u derlemeye kalktığımızda kendi derleme sistemi gereken kütüphanleri orjinal paket içerisinden derlenmiş olarak alıp derliyor. Aksi halde daha önce bahsettiğim kütüphane sürüleri ile ilgili sorunlar çıkabiliyor. Örneğin Jboss üzerinde bir derleme yapıyoruz fakat kullanılan bir kütüphanenin en güncel sürümü bu derleme içerisinde kullanılmamış olabilir. O kütüphanenin güncel sürümünü kullandığımızda büyük ihtimal Jboss'un derleme ve daha kötüsü çalışma zamanı problemleriyle uğraşmak zorunda kalırız. Kaynaktan derlemeden kastınız jbossun kaynak kodunun indirilip derlenmesi mi? Bunun yerine derlenmiş bir jbossu /opt veya /usr altında uygun bir yere açmak daha mantıklı değil mi? Tomcat için de aynı şey geçerli. - Ayni uygulamanin birden fazla sürümünü depoya ekleyebilir miyiz? Bkz. jre5-jre6, tomcat5, tomcat6, jboss4-jboss6 vs. Bence kesinlikle eklenmesi gerekiyor. Aynı sistem üzerinde farklı JVM'ler üzerinde farklı uygulama sunucu sürüleri üzerinde koşan uygulamalar olabiliyor. Sismenin kaynak kullanım problemleri sistei yöneten kişinin sorumluluğunda diye düşünüyorum... Burada sistem yöenticisi bir zahmet diğer sürümleri kendi kursun deniyor olabilir ama özellikle JVM konusunda farklı sürüleri kesinlikle desteklemeliyiz diye düşünüyorum... - Farkli java sanal makine gerceklemelerini paketleyelim mi? (icedtea vs.) Yani is gücünü buldugumuzu var sayiyorum, politik olarak mümkün mü? Bence bu da mümkün olsa iyi olur. Özellikle önümüzdeki dönemde jdk7 ile birlikte Sun/Oracle jvm'i ve OpenJDK ve icedtea kullanıcı tercihine göre kurulması ciddi bir ihtiyaç olacaktır. Ubuntu ve diğer dağıtımlarda OpenJDK geçişleri yapıldı. Sunjdk şimdilik yeterli olsa da openjdknın da depoya girmesi gerekecektir. jdk7 ile de zaten jdk5-6-7 üçlüsü depoda bulunması haliyle gerekecek. - Dosya türlerine göre dizin secimimiz nasil olmali. (birlikte gelen jar paketleri nereye gitmeli, genel olarak opt yada usr altina kurulmali vs.) Bence jvm ve uygulama sunucuları dağıtmamalıyız. Opt altında yaşıyor olabilirler. Dokümanlar ve Loglar için symlink konuyor olabilir. Hatta jvm örnekleri v.s. ayrıca paketleniyor olabilir ama mümkünse orjinal dokümanlarda belirtilen yerlerde bulunuyor olsalar iyi olur. Hakan Uygun -- Uygun Teknoloji Bil.Hiz.Tic.Ltd.Şti. web: www.uygunteknoloji.com tel: +90 212 2589780 gsm: +90 533 2761692 ___ Gelistirici mailing list Gelistirici@pardus.org.tr
Re: [Gelistirici] iş takip aracı ve gelişmeler
2010/8/10 Semen Cirit sci...@pardus.org.tr: Selamlar, Yaklaşık 3 hafta önce Redmine'ı kurup, ilgilenebileceğimi söylemiştim. Redmine'ı kurdum, dışarıdan http://tracker.pardus.org.tr adresi ile erişilebilir durumda. Proje içerisinde kullanacağımız özelliklere bakıldığında Redmine yeni sürümü ile kullanılmak için uygun gibi görünüyor. Ayrıca geçen hafta içerisinde olan bir gelişmeden daha bahsetmek istiyorum. Tüm projelerimizi iyi bir şekilde yürütebilmek adına TUSSİDE'de (Türkiye Sanayi Sevk ve İdare Enstitüsü) 2 günlük proje yönetimi eğitimi aldık. Bu eğitimler teorik ve pratik olmak üzere iki ana bölüm içeriyordu. Pratik eğitimlerimizi Hakan Uygun ile birlikte Redmine üzerinde gerçekleştirdik. 2011 projesi ve diğer teknolojiler (pisi, yalı, kaptan, *-manager ailesi) için nasıl bir proje yönetimi izleyebileceğimizi öğrendik, konuştuk ve tartıştık. Bu eğitimde edinilen bazı bilgilerden kısaca bahsetmek istiyorum: 1. Yaptığımız sürümlerin (2009, 2011, kurumsal vs) ve diğer teknolojilerin kendi başına birer proje olarak düşünülmesinin, proje yönetimi açısından daha iyi olabileceği ortaya çıktı. 2. Redmine ve benzeri uygulamaların iş takibi için var olduğunu ve yapılacakların bu araca girilmeden önce proje planlaması (zamanlama, önceliklendirme) yapılmasının gerekli olduğunu öğrendik. (Bilgilendirme: ) 2011 projesinin planlanması ile ilgilenmeye başladık 1 veya 2 hafta içerisinde bunu tamamlayıp listede paylaşmayı düşünüyoruz.) 3. Birbiri ile ilişki içerisinde olan projelerin nasıl yürütüleceği hakkında bilgi edindik. Örnek vermek gerekirse, birbiriyle ilişkili olan 2011 projesi ve diğer teknolojiler baz alındığında 2011'in kod dondurma tarihi, x teknolojisinin y versiyonunun özelliklerini tamamlamak için de son tarih olacaktır. Bu durum da birbiri ile ilişkili projelerin tasklarının 2011'de dummy bir task'a bağımlı hale getirilip, bu dummy task altında tutulmasıyla gerçekleştirilebilir. Misal, x projesinin a, b, c tasklarını 2011 projesinde bulunan x projesi y versionu bitişi adındaki dummy task'a bağımlı hale getirmek.. Ne dersiniz? 4. iş takibi araçlarının genellikle gündelik yapılacak işler için çok uygun olmadığını öğrendik. Bu durum için de paket yapma, onaylama (Review, ACK-NACK) gibi süreçlerin iş takip sisteminde yer alıp almayacağı Redmine'a geçişimiz sırasında hep beraber kararlaştıracağız. Böyleyken böyle 2011 ile birlikte Redmine'da işlerimizi takip edebileceğimiz bir araca da kavuşmuş olacağız, hayırlısı olsun :) Bu arada dün bir 2011 toplantısı gerçekleştirdik, bunun ile ilgili toplantı notlarını ve Redmine ile 2011'de yapılabilecekleri, Gökçen mail olarak iletecek :) Herkese kolaylıklar, -- Semen Cirit TUBITAK/UEKAE - Pardus GNU/Linux http://www.pardus.org.tr/eng Redmine'a gerekli olabilecek bazı uygulamaları da ekledik Gökmen ile: http://www.redmine.org/wiki/redmine/PluginReStructuredTextFormatter http://www.r-labs.org/projects/r-labs/wiki/Theme_Changer_en http://www.redmine.org/wiki/redmine/PluginGraphs http://www.redmine.org/boards/3/topics/9627 http://www.modula.fi/2009/redmine-theme-modula-mojito/ -- Semen Cirit TUBITAK/UEKAE - Pardus GNU/Linux http://www.pardus.org.tr/eng ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Pardus 2008 Güncellemeleri Sona E riyor - Pardus 2008 Ya?am Sonu
Pardus 2008 güncellemeleri sona eriyor. Kararlı sürümü 27 Haziran 2008 tarihinde yayınlanan ve 15 Eylül 2008'de 2008.1 Hyaena hyaena, 31 Ocak 2009'da ise 2008.2 Canis aureus ara sürümleri ile kullanıcılarıyla buluşan Pardus 2008, güncellemelerini sona erdiriyor. Yayınlanmasının üzerinden geçen 2 yıllık süre içinde, 2009.1 Anthropoides virgo'nun yayınlanması ile sadece güvenlik güncellemelerini sunmaya başlayan Pardus 2008, Pardus 2009.2 Geronticus eremita sürümünün ardından tüm güncellemeleri durduruyor. Bugünden sonra Pardus 2008 depolarına herhangi bir güncelleme girmeyecek, Pardus 2008 için açılan hatalar çözülmeyecek - sunucularımızda Pardus 2008 / Contrib kararlı depolarının son hallerini sunmaya devam edeceğiz, fakat Pardus 2008 / Contrib derleme çiftliği ve test deposunu kapatarak 2008 kaynak paket deposunu donduracağız. Halen Pardus 2008 kullanmakta olan kullanıcılarımızın ise Pardus sistemlerini güvenli ve kararlı bir şekilde kullanmaya devam etmek için dağıtımlarını güncel Pardus 2009 seviyesine yükseltmelerini öneririz. [**] Pardus 2008 bakım ekibi olarak Pardus 2008 sürecine emeği geçen tüm geliştiricilerimize bir kez daha teşekkür ediyoruz - Pardus 2008 tüm geliştiricilerimizin özverili çabaları sayesinde bu kadar başarılı oldu. Her zamanki gibi, iyi ki varsınız :-) -- [**] : upgrade-manager (Dağıtım güncelleme yöneticisi) ile Pardus 2008 - Pardus 2009 geçiş yapmak için aşağıdaki adımları izlemeniz yeterli olacaktır : 1- Paket Yöneticisi'ndeki tüm güncellemeleri yapın. 2- Güncellemeler bittikten sonra, upgrade-manager (Dağıtım güncelleme yöneticisi) isimli paketi kurun. 3- Paket Yöenticisi'nin kapalı olduğundan ve sistem çekmecesinde dahi çalışmadığından emin olun. 4- KDE menüsünde, Programlar - Sistem - Sürüm Yükseltme Aracı (Pardus 2009 Dağıtım Güncellemesi) yolunu takip ederek dağıtım güncellemesini başlatın. 5- Kullandığınız bilgisayarın internete bağlı olduğundan emin olun ve Yükseltmeye Başla düğmesine tıklayarak güncellemeyi başlatın. Güncelleme esnasında sizden bazı paketlerin kaldırılması gerektiğiyle ilgili onay ya da bazı yetki gerektiren işlemler için parola istenebilir. 6- Güncelleme sırasından başka bir işlem yapmamanız ve güncellemeyi kesinlikle kesmemeniz gerekmektedir. 7- Güncelleme bittikten sonra bilgisayarınızın yeniden başlatılması istenecektir, kesinlikle onay vermeniz önerilir. Aksi takdirde kararsız bir sistemle karşı karşıya kalabilirsiniz. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] tags/2008-EOL - 2008 is dead baby, stone-cold-dead...
Merhaba, On Tue, 2010-08-10 at 15:57 +0300, Ekin Meroğlu wrote: Author: eki Date: Tue Aug 10 15:57:07 2010 New Revision: 96789 Added: tags/2008-EOL/ - copied from r96784, 2008/stable/ Log: 2008 is dead baby, stone-cold-dead... Ve bir sürüm daha tarih olur - hepimizin eline sağlık, çok eğlenceliydi :-P -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] trunk/playground/intern/guestlogin - add guestlogin project
Salı 10 Ağustos 2010 günü (saat 16:15:24) Deniz Gürsel şunları yazmıştı: Author: deniz.gursel Date: Tue Aug 10 16:15:24 2010 New Revision: 31367 Added: trunk/playground/intern/guestlogin/ trunk/playground/intern/guestlogin/README trunk/playground/intern/guestlogin/guestlogin.py (contents, props changed) Log: add guestlogin project Deniz gittikten sonra .subversion dizinini temizlemeyi unutmuşuz. Commit'in asıl sahibi Metsutcan Kurt :) ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Güvenlik Güncellemeleri - Secur ity Fixes (2010-08-10)
Merhaba / Hi, Bu gece kararlı depolara girecek güvenlik güncellemeleri; Tonights security fixes for Pardus stable repos; --- * Pardus 2009 gnupg-2.0.11-27-5.pisi qt-4.6.3-78-23.pisi qt-demos-4.6.3-78-5.pisi qt-designer-4.6.3-78-23.pisi qt-devel-4.6.3-78-3.pisi qt-doc-4.6.3-78-23.pisi qt-doc-html-4.6.3-78-5.pisi qt-l10n-4.6.3-78-3.pisi qt-linguist-4.6.3-78-23.pisi qt-sql-ibase-4.6.3-78-23.pisi qt-sql-mysql-4.6.3-78-23.pisi qt-sql-odbc-4.6.3-78-23.pisi qt-sql-postgresql-4.6.3-78-23.pisi qt-sql-sqlite-4.6.3-78-23.pisi xulrunner-1.9.2.8-34-29.pisi xulrunner-devel-1.9.2.8-34-29.pisi firefox-3.6.8-131-34.pisi rekonq-0.5.0-6-3.pisi cabextract-1.3-4-3.pisi kernel-2.6.31.13-131-47.pisi kernel-doc-2.6.31.13-131-30.pisi kernel-firmware-2.6.31.13-131-44.pisi kernel-headers-2.6.31.13-131-47.pisi kernel-module-headers-2.6.31.13-131-39.pisi kernel-source-2.6.31.13-131-47.pisi perf-2.6.31.13-131-13.pisi kernel-module-headers-pae-2.6.31.13-131-28.pisi kernel-pae-2.6.31.13-131-28.pisi iputils-20071127-8-6.pisi vte-0.20.5-8-4.pisi vte-docs-0.20.5-8-4.pisi -- Onur Küçük Knowledge speaks, onur.--.-.pardus.org.tr but wisdom listens ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] 2011 toolchain vs.
On Monday 09 August 2010 20:47:15 Onur Küçük wrote: Farm oluşturmak için kernel (şu anda corporate2 deki kernel düzgün bir şekilde derleniyor, paketlerini cekirdek e koyacağım), subversion, sudo, screen, rsync ve bunların bağımlılıklarına ihtiyacımız var. kernel hariç merge edildi. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] iş takip aracı ve gelişmeler
2010/8/10 Semen Cirit sci...@pardus.org.tr Selamlar, Yaklaşık 3 hafta önce Redmine'ı kurup, ilgilenebileceğimi söylemiştim. Redmine'ı kurdum, dışarıdan http://tracker.pardus.org.tr adresi ile erişilebilir durumda. Proje içerisinde kullanacağımız özelliklere bakıldığında Redmine yeni sürümü ile kullanılmak için uygun gibi görünüyor. Sevgili Semen, Üye olan herkesin otomatik olarak reporter/raporlayıcı yetkileriyle donanmasını sağlarsan iyi edersin. Redmine'da tek tıklık bir ayar bu. Böylelikle hem üyeliklerimizin onaylanmasını beklemeyiz hem de yetkilendirmelerle uğraşacak kişinin işi büyük ölçüde kolaylaşır. Ali ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] iş takip aracı ve gelişmeler
Merhaba, 10 Ağustos 2010 10:49 tarihinde Semen Cirit sci...@pardus.org.tr yazdı: 3. Birbiri ile ilişki içerisinde olan projelerin nasıl yürütüleceği hakkında bilgi edindik. Örnek vermek gerekirse, birbiriyle ilişkili olan 2011 projesi ve diğer teknolojiler baz alındığında 2011'in kod dondurma tarihi, x teknolojisinin y versiyonunun özelliklerini tamamlamak için de son tarih olacaktır. Bu durum da birbiri ile ilişkili projelerin tasklarının 2011'de dummy bir task'a bağımlı hale getirilip, bu dummy task altında tutulmasıyla gerçekleştirilebilir. Misal, x projesinin a, b, c tasklarını 2011 projesinde bulunan x projesi y versionu bitişi adındaki dummy task'a bağımlı hale getirmek.. Ne dersiniz? Çok başarılı bir seçim olur, takibi de kolaylaştıracağını düşünüyorum. 4. iş takibi araçlarının genellikle gündelik yapılacak işler için çok uygun olmadığını öğrendik. Bu durum için de paket yapma, onaylama (Review, ACK-NACK) gibi süreçlerin iş takip sisteminde yer alıp almayacağı Redmine'a geçişimiz sırasında hep beraber kararlaştıracağız. Gündelik işleri Redmine üzerine taşırsak Bugzilla kadar karışır işler, bu seçimin de doğru olduğuna inanıyorum. Sevgiler -- Ahmet AYGÜN ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] tags/2008-EOL - 2008 is dead baby, stone-cold-dead...
2007'den sonra en sevdigim surumdu, huzur icinde yatsin :P 2010/8/10 Ekin Meroğlu e...@pardus.org.tr: Merhaba, On Tue, 2010-08-10 at 15:57 +0300, Ekin Meroğlu wrote: Author: eki Date: Tue Aug 10 15:57:07 2010 New Revision: 96789 Added: tags/2008-EOL/ - copied from r96784, 2008/stable/ Log: 2008 is dead baby, stone-cold-dead... Ve bir sürüm daha tarih olur - hepimizin eline sağlık, çok eğlenceliydi :-P -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] tags/2008-EOL - 2008 is dead baby, stone-cold-dead...
Ops, Ekin'e gondermek yerine listeye gonderdim yanlislikla. Ozur dilerim... 2010/8/10 S.Çağlar Onur cag...@pardus.org.tr: 2007'den sonra en sevdigim surumdu, huzur icinde yatsin :P 2010/8/10 Ekin Meroğlu e...@pardus.org.tr: Merhaba, On Tue, 2010-08-10 at 15:57 +0300, Ekin Meroğlu wrote: Author: eki Date: Tue Aug 10 15:57:07 2010 New Revision: 96789 Added: tags/2008-EOL/ - copied from r96784, 2008/stable/ Log: 2008 is dead baby, stone-cold-dead... Ve bir sürüm daha tarih olur - hepimizin eline sağlık, çok eğlenceliydi :-P -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
