Bazel Bakımı Kılavuzları

Nightly · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

Bu kılavuz, Bazel açık kaynak projesinin bakımcıları içindir.

Bazel'e katkıda bulunmak istiyorsanız bunun yerine Contributing to Bazel (Bazel'e Katkıda Bulunma) başlıklı makaleyi okuyun.

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

  1. Projenin katkı süreciyle ilgili olarak bakımcıların doğru kaynak olarak kullanacağı yerdir.
  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 Ekip: Bazel CI'nın durumunu izler ve kesintileri bildirir.
  • 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. {: .external}
  3. DevEx üyesi, sorunu inceledikten sonra hemen ilgilenilmesi gerekip gerekmediğine karar verir. Bu durumda, ekip liderleri listesinden bir sahip ve P0 öncelik etiketi atanır.
  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 bir platform: etiketi atar. Örneğin, Mac'e özgü sorunlar için platform:apple etiketi atanır.
  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ğerlendirecek ve mümkünse çözüm sunacak. Bir takım etiketi 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 işlemelerini dahili test paketiyle karşılaştırarak test etmemiz gerekir. Bu nedenle, PR'ler doğrudan birleştirilmez.
  6. İçe aktarılan commit tüm dahili testleri geçerse commit birleştirilir ve GitHub'a geri 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

Çekme istekleri (PR'ler), harici katkıda bulunanların Bazel'e değer katmasının temel yoludur. Açık kaynaklı bir proje olarak, çekme isteklerinin zamanında ve verimli bir şekilde incelenip ele alınmasını sağlamak önemlidir.

  • Öncelik belirleme

    awaiting-review etiketi ve ekip etiketinizle gelen PR'leri düzenli olarak inceleyin. Bu işlem, rotasyon veya düzenli bir önceliklendirme toplantısıyla yapılabilir. Her PR'ye 7 iş günü içinde ilk yanıtın verilmesini bekliyoruz.

  • Yanıt

    • PR iyi görünüyorsa onaylayın ve awaiting-PR-merge etiketini uygulayın. gTech ekibi, PR'yi CL olarak içe aktarır.
    • Aksi takdirde geri bildiriminizi gönderin ve awaiting-review etiketini awaiting-user-response etiketiyle değiştirin. PR yazarı yanıt verirse DevEx alt ekibi etiketi düzenli olarak günceller.
    • Büyük değişiklikler içeren PR'ler için tasarım belgesi veya sorunda önceden yapılan tartışma isteyebilirsiniz.

  • Kapanış

    Kaynaklar sınırlı olduğundan Bazel'in standartlarını karşılamayan veya inceleme ya da bakımını yapma kapasitemizin olmadığı çekme isteklerini kapatmamız önemlidir.

    • ÇPR, Bazel'in hedefleriyle uyumlu değilse bunu bir açıklama yaparak kapatın.
    • PR çok büyük ve karmaşıksa daha küçük parçalara ayırma isteğiyle kapatın.
    • PR kodu kalitesi standartlarımızı karşılamıyorsa kodu bir açıklama ile kapatın.
    • Kodun gelecekteki bakım maliyeti çok yüksekse kodu bir açıklama ile kapatın.
    • PR uzun süredir kullanıcı yanıtı bekliyorsa ve katkıda bulunan kullanıcı yanıt vermediyse PR 30 gün sonra otomatik olarak eski olarak işaretlenir ve 30 gün sonra kapatılır.

    Bir çekme isteğini kapatırken nazik olun ve kapatma nedenini açıklayın.

Öncelik

Öncelik için aşağıdaki tanımlar, sorunları önceliklendirmek üzere bakımcılar tarafından 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 hizmet kesintisi. 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 bulunmamaktadır.
  • 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 öncelik verilmez 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 olası bir yeniden önceliklendirme için de açık tutulabilir.

Ekip etiketleri

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

Etiketlerin tam listesini burada görebilirsiniz.