Bazel Bakımı Kılavuzları

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

Bu kılavuz, Bazel açık kaynak projesinin bakımını yapanlar içindir.

Bazel'e katkıda bulunmak istiyorsanız lütfen Bazel'e Katkıda Bulunma başlıklı makaleyi okuyun.

Bu sayfanın amaçları şunlardır:

  1. Bakımcıların, projenin katkı süreciyle ilgili doğru bilgi kaynağı olarak kullanacağı bir doküman oluşturun.
  2. Topluluk katkıda bulunanları ile proje bakımcıları arasında beklentileri belirleyin.

Bazel'in çekirdek katkıda bulunanlar grubu, açık kaynak projenin çeşitli yönlerini yönetmek için özel alt ekiplere sahiptir. Desteklenen biçimler şunlardır:

  • Yayın Süreci: Bazel'in yayın sürecini yönetin.
  • Yeşil Takım: Kurallar ve araçlardan oluşan sağlıklı bir ekosistem oluşturun.
  • Geliştirici Deneyimi Bahçıvanları: Harici katkıları teşvik etme, sorunları ve çekme isteklerini inceleme ve geliştirme iş akışımızı daha açık hale getirme.

Sürümler

Sürekli Entegrasyon

bazelbuild/continuous-integration deposunda Green Team'in Bazel'in CI altyapısıyla ilgili kılavuzunu okuyun.

Sorunların yaşam döngüsü

  1. Kullanıcı, sorun şablonlarından birini seçerek sorun oluşturur ve bu sorun, incelenmemiş açık sorunlar havuzuna girer.
  2. Geliştirici Deneyimi (DevEx) alt ekibinin rotasyonundaki bir üye sorunu inceler.
    1. Sorun hata veya özellik isteği değilse DevEx üyesi genellikle sorunu kapatır ve kullanıcının sorunun daha görünür olması için StackOverflow ve bazel-discuss'a yönlendirir.
    2. Sorun, topluluğa ait rules_apple gibi bir kurallar deposuna aitse DevEx üyesi bu sorunu doğru depoya aktarır.
    3. Sorun belirsizse veya eksik bilgi varsa DevEx üyesi, devam etmeden önce daha fazla bilgi istemek için sorunu kullanıcıya geri atar. Bu durum genellikle kullanıcının doğru sorun şablonunu seçmemesi veya eksik bilgi sağlaması nedeniyle ortaya çıkar.
  3. DevEx üyesi, sorunu inceledikten sonra hemen ilgilenilmesi gerekip gerekmediğine karar verir. Bu durumda, P0 öncelik etiketini ve ekip liderleri listesinden bir sahibi atar.
  4. DevEx üyesi, yönlendirme için untriaged etiketini ve tam olarak bir ekip etiketini atar.
  5. DevEx üyesi, sorunun türüne göre tam olarak bir type: etiketi (ör. type: bug veya type: feature request) de atar.
  6. Platforma özgü sorunlar için DevEx üyesi, Mac'e özgü sorunlar için platform:apple gibi bir platform: etiketi atar.
  7. Sorun düşük öncelikli ve yeni bir topluluk katkıda bulunanı tarafından çözülebilecekse DevEx üyesi good first issue etiketini atar. Bu aşamada sorun, önceliklendirilmemiş açık sorunlar havuzuna girer.

Her Bazel alt ekibi, sahip oldukları etiketler altındaki tüm sorunları tercihen haftalık olarak önceliklendirecektir. Alt ekip, sorunu inceleyip değerlendirir ve mümkünse çözüm sunar. Bir takım etiketinin sahibiyseniz daha fazla bilgi için bu bölüme bakın.

Çözülen sorunlar kapatılabilir.

Pull isteğinin yaşam döngüsü

  1. Kullanıcı bir çekme isteği oluşturur.
  2. Bir Bazel ekibinin üyesiyseniz ve kendi alanınızla ilgili bir çekme isteği gönderiyorsanız ekibinizin etiketini atamaktan ve en iyi incelemeciyi bulmaktan siz sorumlusunuz.
  3. Aksi takdirde, günlük önceliklendirme sırasında bir DevEx üyesi, yönlendirme için bir ekip etiketi ve ekibin teknik yöneticisini (TL) atar.
    1. TL, isteğe bağlı olarak PR'yi incelemesi için başka birini atayabilir.
  4. Atanan incelemeci, PR'yi inceler ve onaylanana veya bırakılana kadar yazarla birlikte çalışır.
  5. Onaylanırsa incelemeci, daha fazla test için PR'nin commit'lerini Google'ın dahili sürüm kontrol sistemine aktarır. Bazel, Google'da dahili olarak kullanılan derleme sistemiyle aynı olduğundan tüm çekme isteği (PR) taahhütlerini dahili test paketiyle karşılaştırarak test etmemiz gerekir. Bu nedenle, PR'leri doğrudan birleştirmeyiz.
  6. İçe aktarılan commit tüm dahili testleri geçerse commit sıkıştırılır ve tekrar GitHub'a aktarılır.
  7. Commit ana dala birleştirildiğinde GitHub, çekme isteğini otomatik olarak kapatır.

Ekibim bir plak şirketine sahip. Ne yapmalıyım?

Alt ekipler, sahip oldukları etiketlerdeki tüm sorunları tercihen haftalık olarak önceliklendirmelidir.

Sorunlar

  1. Sorun listesini ekip etiketiniz ve untriaged etiketine göre filtreleyin.
  2. Sorunu inceleyin.
  3. Öncelik düzeyini belirleyin ve etiketi atayın.
    1. Sorun P0 ise DevEx alt ekibi tarafından önceliklendirilmiş olabilir. Gerekirse yeniden önceliklendirin.
    2. Her sorunda tam olarak bir öncelik etiketi olmalıdır. P0 veya P1 önceliğinde olan sorunların üzerinde aktif olarak çalışıldığını varsayarız.
  4. untriaged etiketini kaldırın.

Etiket ekleyip kaldırabilmek için bazelbuild organization kuruluşunda olmanız gerektiğini unutmayın.

Pull İstekleri

  1. Çekme istekleri listesini ekip etiketine göre filtreleyin.
  2. Açık pull isteklerini inceleyin.
    1. İsteğe bağlı: İnceleme için atandıysanız ancak bu görev için uygun değilseniz uygun incelemeciyi kod incelemesi yapması için yeniden atayın.
  3. Kod incelemesini tamamlamak için çekme isteğini oluşturan kişiyle birlikte çalışın.
  4. Çekme isteğini onaylayın.
  5. Tüm testlerin başarılı olduğundan emin olun.
  6. Yama dosyasını dahili sürüm kontrol sistemine aktarın ve dahili ön gönderme işlemlerini çalıştırın.
  7. Dahili yamayı gönderin. Yama başarıyla gönderilip dışa aktarılırsa PR, GitHub tarafından otomatik olarak kapatılır.

Öncelik

Öncelik için aşağıdaki tanımlar, bakımcılar tarafından sorunları önceliklendirmek için kullanılır.

  • P0: Bazel sürümünün (yayın adayları hariç) kullanılamamasına neden olan büyük bir işlev bozukluğu veya Bazel projesinin geliştirilmesini ciddi şekilde etkileyen bir hizmetin devre dışı kalması. Yeni bir sürümde kullanıma sunulan ve önemli sayıda kullanıcının erişimini engelleyen gerilemeler veya Breaking Change (Kapsamlı Değişiklik) politikasına uygun olmayan, uyumsuz bir kapsamlı değişiklik bu kapsamdadır. Pratik bir geçici çözüm yoktur.
  • P1: Bir sonraki sürümde ele alınması gereken kritik bir kusur veya özellik ya da Bazel projesinin geliştirilmesi de dahil olmak üzere birçok kullanıcıyı etkileyen ciddi bir sorun ancak pratik bir geçici çözüm mevcut. Genellikle acil işlem yapılması gerekmez. Yüksek talep görüyor ve mevcut çeyreğin yol haritasında planlanıyor.
  • P2: Ele alınması gereken ancak şu anda üzerinde çalışmadığımız kusur veya özellik. Yayınlanmış bir Bazel sürümünde, gelecekteki bir sürümde düzeltilmesi gereken ve/veya kolay bir geçici çözümü olan, kullanıcı için rahatsız edici bir canlı sorun.
  • P3: Küçük bir hata düzeltmesi veya küçük bir etkiye sahip iyileştirme isteniyor. Bazel yol haritalarında veya yakın zamanda yayınlanacak sürümlerde önceliklendirilmez ancak topluluk katkıları teşvik edilir.
  • P4: Kapatılma olasılığı düşük olan, düşük öncelikli kusur veya özellik isteği. Daha fazla kullanıcı etkilenirse yeniden önceliklendirme olasılığı için açık tutulabilir.

Takım etiketleri

Yeni sorunlar için ekip etiketleri yerine category: * etiketlerinin desteğini sonlandırdık.

Etiketlerin tam listesini burada bulabilirsiniz.