Git ve Debian gibi bazı büyük projeler neden yalnızca bir posta listesi kullanıyor, sorun takipçisi değil?


65

Herhangi bir makul büyüklükteki projenin hata takipçisi bana biraz zekice davranıyor gibi gözüküyor - yüzlerce veya binlerce sorunu organize etmeyi gerçekten kolaylaştırıyor, sorunları çarpışmadan veya karışmadan.

Bu yüzden Git gibi gerçekten büyük projeler gördüğümde, bir e-posta listesini bakım ve geliştirmeyi koordine etmek için ana yöntem olarak kullanmaya başladım. Örnekler:

  • Git - Topluluk sayfası:

    ... Hata raporları bu posta listesine gönderilmelidir.

  • Debian hata takip sistemi , Wikipedia'ya göre:

    ... Özgün özelliği, hata raporlarını düzenlemek için herhangi bir web arayüzüne sahip olmamasıdır - tüm değişiklikler e-posta yoluyla yapılır.

Birçok modern hata takipçisi, e-posta ile çok iyi bir entegrasyona sahiptir (izlemekte olduğunuz veya size atanan hatalar hakkında yorum veya bildirim alabilirsiniz) ve sürüm kontrol sistemlerine (taahhütler bir sorunu çözme, vb. Olarak işaretlenebilir). .). Bunun bir e-posta listesiyle manuel olarak yapılması gerekir ve ilgilenmediğiniz hatalarla ilgili tonlarca e-posta alırsınız.

Peki, bir posta listesinin web tabanlı bir hata izleyiciye göre başlıca avantajları nelerdir? Neden bazı büyük projeler yalnızca bir posta listesi kullanıyor?


2
Evet, hayır, size katılıyorum, Git e-posta listelerini kullanıyor :) Söylediğim şey, "gerçekten büyük projeler" ile karıştırdığınızı ve sadece bunu yaparsanız biraz daha fazlasını vermeniz gerektiğini düşünüyorum. Bu gerçekten büyük projeler için örnekler. Aksi halde soru "Git posta listesini kullanıyor, neden böyle?" bu durumda Jörg W Mittag'ın cevabı daha uygun olur ...
Shivan Dragon

1
Hrm, pek çok şey olduğu izlenimindeydim ... Debian bir mail listesinden daha karmaşık olsa da mail tabanlı bir sistem kullanıyor . Tamam, ama asıl mesele, 'Bir hata listesi üzerinde bir posta listesi kullanmanın avantajları nelerdir?' Cevabı "hiç yok, olmadığı sürece, git geliştiricileri sadece luddites".
naught101

@ naught101: bunu görünce neden havaya uçuruluyor? Debian kararsız , yamalı ya da altı ay boyunca kolayca yeniden başlatmaya gerek duymadan uzaktan kök kötüye kullanımı görmeden kurulabilir ve kullanılabilir. Bu Debian'ın dengesiz versiyonu için . Çalışma süresinin 4 basamağına ulaşan Debian sunucularını kilitledim. Bu adamlar en son teknolojiyi kullanmıyor olabilirler, ama belli ki doğru şeyler yapıyorlar. Her zaman Debian'ın kararlılığı için web hata izleyicilerinden vazgeçtim.
Cedric Martin

2
@CedricMartin: Biliyorum, katılıyorum. Posta listesi hata takibi, bazı takımlar için yeterli bir şekilde çalışır, ancak yine de, bir hata izleyiciden daha az kolay görünüyor. Yine de, temel proje geliştiricileri için farkın çok küçük görünebileceğini düşünüyordum: zaten olan her şeyi takip ediyorlar. Ancak yeni gelenler için, bir posta listesi grok yapmak neredeyse imkansızdır, bu nedenle proje uygunluğuna basit bir genel bakış yapılamaz. Bir hata izleyici, yeni kullanıcıların / geliştiricilerin bir projenin nasıl hareket ettiğini hızlı bir şekilde anlayabilmelerini ve çekirdek ekip tarafından hangi iyileştirmelerin önemli olduğu konusunda bir fikir edinmelerini sağlar.
naught101

Greg Kroah-Hartman, bu tartışmanın bir parçası olarak Linux Çekirdeği ile ilgili olduğu için bunu üstlendi . Özellikle: " Github / gerrit / gitorious modelinin çekirdeğe göre çalışmasının
naught101

Yanıtlar:


45

Gözlemlediğiniz tercih, GNU Kodlama Standartlarında açıkça belirtilen tavsiyelerin doğal bir sonucu gibi görünüyor . Aşağıdaki alıntıda görebileceğiniz gibi hataları e-postayla bildirmenizi önerir ( gözlemlerinize doğrudan hitap eden kısmı kalın işaretli olarak işaretledim ):

4.7.2 --help

Standart --helpseçenek, programın nasıl çağrılacağına dair kısa bir belgeyi standart çıktıda yazmalı ve daha sonra başarıyla çıkmalıdır. Bu görüldüğünde diğer seçenekler ve argümanlar göz ardı edilmeli ve program normal işlevini yerine getirmemelidir.

‘--help’Seçeneğin çıktısının sonuna gelindiğinde , lütfen hata raporları için e-posta adresini , paketin ana sayfasını (normalde ‘http://www.gnu.org/software/pkg’ve GNU programlarını kullanma konusunda yardım için genel sayfayı) içeren satırları yerleştirin . Biçim şöyle olmalıdır:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Diğer uygun posta listeleri ve web sayfalarından bahsetmek mümkündür.

Yukarıda tercih, yukarıda e-postanın bir elektronik iletişim biçimi olarak evrensel olarak kabul edildiğini yansıtır. --helpYukarıda önerildiği gibi herhangi bir kullanıcının okuma mesajı, bir hata mesajı gördüklerinde ne yapmaları gerektiğini kolayca anlamalıdır.

Sayı izci olabilir (ve sanırım olduğunu ) projesinde çalışan bir geliştirici için daha iyi, ama daha geniş bir kitleye için mevcut ve özellikle hesap çeşitli dikkate alarak ve farklı arasındaki farklar, nasıl kullanılacağını açıklamak zor olurdu sorun izleme sistemleri .

Bir proje Bugzilla'yı kullanabilir, bir diğeri JIRA'ya sadık kalır , üçüncü ... GNATS , vb. Vb. Tüm bu "hayvanat bahçesini" standart ve tek tip olacak şekilde sunmanın hiçbir yolu yoktur.

Report bugs to: mailing-address


Yukarıdaki not, projelerin sorun izleyiciyi dahili olarak kullanmaması gerektiği anlamına gelmez . İlgili soruya mükemmel bir cevapta açıklandığı gibi ,

Hata takipçiniz, müşterileriniz için değil, sizin rahatınız için. Telefon veya e-posta sorunlarını alıp kendinize girmekle rahatsız edilemezseniz, nasıl hissettiğini düşünüyorsunuz?

Sorun girebilmeniz ve bunları bir müşteriye manuel olarak atamanız gerekir ...


3
Mükemmel cevap! E-posta, sorun izleyiciden daha iyi bilinir ve anlaşılması daha kolaydır (bu herkesin "e-posta aldığını" söylemez): P)
Andres F.

21
Ayrıca, bu GNU tavsiye, antik olduğu yolu web ve web tabanlı sorun izleyiciler daha yaşlı.
Ross Patterson

@RossPatterson Bunu düşünüyordum. Ancak, bir sürü URL içerdiği düşünüldüğünde, web’den daha büyük görünmesi olası görünmüyor ...
naught101

6
@gnat: Bu bağlantılı cevabın büyük bir kısmı bu kadar büyük olmak, "eğer sizin için kolaysa , bu tür şeyleri oraya girebilirsiniz" kısmıdır. Telefon desteği için finansman olmadığı için birçok açık kaynaklı projenin anahtarı budur. Bir posta listesi hata bildiren bir kullanıcı olarak benim için bir cevaptır, çünkü yanıtlara kaydolmak zorunda kalmak istemiyorum. Bir hata izleyiciyle, sahip olduğum sorunun sistemde olduğunu görebiliyorum ve daha sonra geri dönüp araştırabilir ve güncellendiğini görebiliyorum. Bu, genellikle iyi durumda olmayan, web tabanlı bir liste izleyici olmadan, bir posta listesi için zordur.
naught101

1
@ naught101 Web'den daha eski olmayabilir ama kesinlikle Web tabanlı izleyicilerden daha eski olabilir
sakisk 16:13 'de

30

Özellikle Git ile basit bir tarihi sebep var: Git Linux korsanları tarafından Linux korsanları için başlatıldı ve Linux'un yaptığı gibi aynı geliştirme modelini ve araçlarını kullandı. Linux, ancak, sadece Linux orada başlatıldığında, WWW daha yaşlı, yani hiçbir vardı web tabanlı sorun takip var çünkü, hiçbir idi web!

Sonuç olarak, Linux topluluğu hata raporları ve e-posta üzerinden kod incelemeleri ile başa çıkmak için son derece verimli araçlar ve iş akışları geliştirdi ve tüm bu işleri atıp, Git projesini başlattıklarında sıfırdan başlamaları için hiçbir neden yoktu.


3
WWW’nin Linux’tan önce geldiğini düşündüm. Hafif, az oranda, belli belirsiz. İkisi de aynı anda ve farklı insan grupları tarafından yapıldı. 90'lı yılların ortasına kadar ya da patlayan değildi.
Donal Fellows

6
Tamam, ama linux çekirdeğinin artık bir hata izleyicisi var: bugzilla.kernel.org . Açıkçası bu kadar büyük bir engel değil.
naught101

7
-1 Git, ağdan çok daha genç. Vintage 2005. O sırada elbette Bugzilla da dahil olmak üzere birçok sorun takipçisi vardı. Linus sadece sorun izleyiciden hoşlanmıyor ve sözleri o ortamdaki yasa.
Ross Patterson,

6
@RossPatterson - Linux'un Git'ten değil webden daha eski olduğunu söyledi. Söylediklerinizi temelde tekrarladığınızdan, yorumunuzun aşağı oy kullanmasını haklı çıkardığını sanmıyorum.
Beatgammit

2
@tjameson Gezide, haklısın. Nötr'e geri dön.
Ross Patterson,

17

Git için:

Posta listesinde, insanların bir tür hata izci kullanmayı önerdiği bazı tartışmalar var. Bu girişimlerin hepsinin perişan olduğu görülüyor, Git'in bir hata izleyici kullanmamasının nedeni, muhtemelen çoğu katılımcı bunu yararlı bulmuyor.

Posta listesindeki bir yazıda , Junio ​​C Hamano (Git'in sorumlusu) neden bir hata takipçisinin çok kullanışlı olmadığını düşündüğünü özetledi. Mesajın tamamını dahil etmek istemiyorum (oldukça uzun), ancak aşağı kayıyor:

  • Yalnızca çözülmüş problemler hakkında bilgi arıyorsanız, liste arşivlerinde arama yapmak bir hata izleyiciyi aramanın yanı sıra çalışır.
  • Gerçek bir hata bildirirseniz ve insanlar bununla ilgilenmek istiyorsa, liste de iyi çalışır.
  • Hiç kimse bir problem üzerinde çalışmak istemiyorsa, bir hata takipçisinde bile olsa, çatlaklardan düşecektir.
  • Bir hata izci, yeni hataların düzenli olarak kontrol edilmesi, sabit hataların kapatılması vs.

5
İyi cevap, ancak 3. puanınızın e-postaların büyük bir dezavantajı olduğunu savunuyorum: Eğer bir hatanın düzeltilmesi zorsa ve mevcut aygıtlar tembel ise, sorun izleyicideki bir girişten çok daha fazla gömülür. Bu, belirli hataların hiçbir zaman düzeltilmediği anlamına gelebilir, çünkü insanlar orada olduklarını bilmiyorlar
TheLQ

1
@TheLQ: Doğru. Ancak, görünüşe göre bu bazı projeler almak isteyen bir risk. Ve adil olmak gerekirse, git bir hata takipçisi olmasa bile oldukça sağlam bir yazılımdır.
sleske

1
@TheLQ: Bilinen tüm hataları (ve ilgili konuları) anlatan basit bir web sayfası bunu çözmez mi? Buna benzeyen bir şey , bu bağlantılar arşiv arşivine işaret ediyor.
Merhaba Dünya

1
@HelloWorld: Bu, (basit) bir sorun izleyici olurdu. Ve tıpkı bir sorun izci gibi, birisinin yönetmesi gerekecekti ...
sleske

Ben abone olmadığım zamanlarda gönderilen e-postanın çevrimdışı bir kopyasını almanın iyi bir yolu var mı?
PSkocik

6

Debian bir hata izleyici kullanıyor, varsayılan arayüzü e-posta. Ve uygun. Debian Proje Lideri Lucas Nussbaum birkaç gün önce gönderildi :

Debugs, Debian Bugs Tracking System'in (BTS) arkasındaki bir yazılımdır. Ayrıca GNU projesi tarafından da kullanılır. Genellikle eski tarz olarak algılanmasına rağmen, paketin her bir sürümünde ve paketin dalındaki hata durumlarının izlenmesi gibi) veya tüm etkileşimleri e-posta yoluyla gerçekleştirme, çalışmayı çok kolaylaştırma gibi çeşitli benzersiz özelliklere sahiptir çevrimdışı veya kötü bağlanmış ortamlarda.

Son kısım, burada öldürücü bir özellik - sadece uçaktan inene kadar bu raporları yerel posta kuyruğunda sıraya koy!


4
  • 9 yaşındakileri dışarıda tutar.
  • Her forum için ayrı bir hesap oluşturmanıza gerek yok.
  • [minor] Farklı posta listelerinde tutarlı bir kullanıcı deneyimi ve yeni bir listeye abone olurken sıfır bir öğrenme eğrisi.
  • Çevrimdışı çalışıyor. İnternete bağlanıp bir sürü posta indirebilir, daha sonra yürüyüş yapabilir, ana doğanın tadını çıkarırken cevaplarınızı yazabilir ve daha sonra gönderebilirsiniz.
  • Posta şifrelemeye ve / veya GPG ile imzalamaya izin verir.
  • Merkezi olmayan - Forum çökerse hala bir kopyasına sahip olacaksınız, kurcalamaya karşı dayanıklı, kötü bir moderatör / hacker söylediklerinizi kolayca kurcalayamaz. Kimse tarihi geri alamaz.
  • Filtrelere, klasörlere ve bir E-posta istemcisinin tüm gelişmiş organizasyon özelliklerine izin verir.
  • "Push bildirimleri" - E-posta istemcinizi açık bırakabilir ve yeni cevapların bildirimlerini alabilirsiniz.
  • Hepsine hükmedecek tek bir yer - farklı siteler arasında atlama yapmanıza gerek yok.
  • Web ile ilgili tüm güvenlik açıklarına karşı korunma (html / javascript / enjeksiyonlar, vb.)
  • Kabartmak yok - Rozet yok, süslü imzalar, reklamlar, web işaretçileri, javascript kabartması. Her şey basit ve konuya göre - tartışma.
  • LAMP kurulumundan daha az sunucu yükü.

Akla gelen posta listelerinin bir dezavantajı, posta listelerinin olmasa da forumların kategorilere ve alt kategorilere ayrılabilir olmasıdır. Bu, bir posta listesini birkaç posta listesine bölerek taklit edilebilir ve ardından kullanıcılar her bir mesajı ilgili klasöre koymak için uygun filtreleri kullanabilir (Her klasör bir kategoridir). Web forumlarında bu otomatiktir.


neden insanlar sorunları izlemek için web tabanlı versiyonlar oluşturmakta ısrar ediyorlar (BTW bu soru her şeyle ilgili değil ) başka bir soruda tartışılıyor: Kullanıcıların iyi ve kullanışlı hata raporları yazmasını sağlamak "Kullanıcı tarafından düzenlenebilir çevrimiçi hata raporları öğretmenin en etkili yolu kullanıcılar geliştirir ... "
gnat

Teşekkür ederim. Fakat bu bir aşağı oyu haklı kılıyor mu? Bu cevabın ana konusu bir ML'nin avantajları ve orijinal soruyu oldukça iyi cevaplıyor. Ben "web forumları" rant kaldırıldı.
Merhaba Dünya

2
Bu cevapta bahsedilen dezavantaj aslında aslında çoğu dev mail listesine bağlı kalmamı engelliyor. Her şeyi gönderiyorlar , bu yüzden bir hatayı bildirdikten sonra genellikle sadece iki hafta sonra üyeliğimi iptal ediyorum. Böcek avcıları bu sorunu güzel bir şekilde çözerek belirli hata raporlarına abone olmamı sağladılar.
Roman Starkov

6
Düzeltme: 25 yaşını dışarıda tutar . Ancak geçenlerde bu postaların bazı gerçek projelere katkıda bulunmak için işlerin nasıl yürüdüğünü öğrendim . Ve bundan nefret ediyorum!!
Ciro Santilli,

2
"Her forum için ayrı bir hesap oluşturmanıza gerek yok." - genellikle spam'i önlemek için listeye kaydolmanız gerekir. Ancak bu tüm e-postalara abone. Bu yüzden abone olmanız ve 'spam' durumundan çıkmanız ve sizi CC veya TO'da tutmak için istek eklemeniz gerekir. Bugzilla ile karşılaştırıldığında yapılacak çok şey var.
Maciej Piechotka
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.