מדריך למתחזקי בניין

זהו מדריך בנוגע לתחזוקת הפרויקט של קוד פתוח ב-Bazel.

אם ברצונך לתרום ל-Bazel, יש לקרוא במקום זאת על תרומת תוכן ל-Bazel.

המטרות של הדף הזה הן:

  1. שימשו כתחזוקה ו-# מקורות. לספק המהימנות בתהליך התרומה של הפרויקט.
  2. הגדרת הציפיות בין תורמי הקהילה לבין מנהלי הפרויקט.

לקבוצת הליבה של תורמי התוכן ב-Bazel יש צוותי משנה ייעודיים לניהול ההיבטים של פרויקט הקוד הפתוח. הבדלים אלו הם:

  • תהליך שחרור: ניהול תהליך ההפצה של Bazel&33.
  • צוות ירוק: תוכלו לפתח סביבה עסקית תקינה של כללים וכלים.
  • גננים בעלי ניסיון במפתחים: מעודדים את המשתמשים להוסיף תוכן חיצוני, בודקים בעיות ושולחים בקשות, והופכים את תהליך הפיתוח שלנו לפתוח יותר.

פריטי תוכן

שילוב מתמשך

קראו את המדריך של הצוות הירוק ל-Bazel' על מאגר הנתונים של bazelbuild/Continuous-int-Integration.

מחזור החיים של בעיה

  1. משתמש יוצר בעיה באמצעות תבנית הבעיה והוא נכנס למאגר של בעיות פתוחות שלא נבדקו.
  2. חבר בקבוצת המשנה 'חוויית המפתח' (DevEx) בודק את הבעיה.
    1. אם הבעיה היא לא באג או בקשת תכונה, חבר המועדון של DevEx בדרך כלל יסגור את הבעיה ויפנה את המשתמש אל StackOverflow ובדיון כדי לראות טוב יותר את השאלה.
    2. אם הבעיה שייכת לאחד ממאגרי הכללים שבבעלות הקהילה, כמו rules_apple , חבר המועדון של DevEx יעביר את הבעיה הזו למאגר הנכון.
    3. אם הבעיה אינה ברורה או שחסר בה מידע, מנוי DevEx יקצה את הבעיה בחזרה למשתמש כדי לבקש מידע נוסף לפני המשך. מצב זה קורה בדרך כלל כשהמשתמש לא מקפיד לפעול בהתאם לתבנית הבעיה.
  3. לאחר בדיקת הבעיה, חבר המועדון של DevEx מחליט אם הבעיה מחייבת תשומת לב מיידית. אם כן, הוא יקצה את התווית P0 עדיפות ובעלים מרשימת הלידים של הצוות.
  4. חבר המועדון של DevEx מקצה את התווית untriaged ותווית צוות אחת בלבד לצורך הניתוב.
  5. מנוי של DevEx מקצה גם תווית type: אחת, למשל type: bug או type: feature request, בהתאם לסוג הבעיה.
  6. עקב בעיות ספציפיות לפלטפורמה, מנוי DevEx מקצה תווית platform: אחת, למשל platform:apple לבעיות ספציפיות ל-Mac. בשלב זה, הבעיה נכנסת למאגר של בעיות פתוחות ולא פעילות.

כל צוות משנה ב-Bazel יקצה עדיפות לכל הבעיות השייכות לתוויות שבבעלותן, ועדיף על בסיס שבועי. צוות המשנה יבדוק את הבעיה, יבחן אותה ויספק אותה אם אפשר. אם יש לכם תווית של צוות, מומלץ לעיין בקטע הזה לקבלת מידע נוסף.

כשבעיה נפתרת, אפשר לסגור אותה.

מחזור החיים של בקשת משיכה

  1. משתמש יוצר בקשת משיכה.
  2. אם אתם חלק מצוות Bazel ושולחים יחסי ציבור לאזור שלכם, אתם אחראים להקצות את תווית הצוות ולמצוא את הסוקר הטוב ביותר.
  3. אחרת, במהלך מיון יומי, חבר ב-DeEx מקצה תווית צוות אחת וליד טכני (TL) לצוות.
    1. ייתכן ששירות ה-TL יקצה למישהו אחר לבדוק את יחסי הציבור.
  4. הכותב שבודק את התוכן בודק את יחסי הציבור ופועל עם המחבר עד לאישור או לדחייה.
  5. אם הבקשה תאושר, הבודק יייבא את מערכת PR's למערכת הפנימית של Google לבדיקות נוספות. מאחר ש-Bazel זהה לאותה מערכת build שנעשה בה שימוש פנימי ב-Google, עלינו לבדוק את כל עמלות יחסי הציבור מול חבילת הבדיקה הפנימית. זו הסיבה לכך שאנחנו לא ממזגים את יחסי הציבור באופן ישיר.
  6. אם הנציבות המיובאת תעבור את כל הבדיקות הפנימיות, העמלה תיעלם ותיוצא שוב אל GitHub.
  7. כאשר המחויבות מתמזגת למאסטר, GitHub סוגר את ה-PR באופן אוטומטי.

הצוות שלי הוא הבעלים של התווית. פעולות מומלצות

צוותי משנה צריכים למיין את כל הבעיות בתוויות שבבעלותם, רצוי על בסיס שבועי.

מהדורות

  1. מסננים את רשימת הבעיות לפי תווית הצוות וגם לפי התווית untriaged.
  2. בודקים את הבעיה.
  3. לזהות רמת עדיפות ולהקצות את התווית.
    1. ייתכן שצוות המשנה של DevEx כבר קיבל את הבעיה של העדיפות, אם מדובר ב-P0 39. צריך לקבוע סדר עדיפויות לפי הצורך.
    2. כל בעיה צריכה לכלול תווית עדיפות אחת בדיוק. אם הבעיה היא P0 או P1, אנחנו מניחים שעובדת באופן פעיל.
  4. יש להסיר את התווית untriaged.

לתשומת ליבך, כדי להוסיף או להסיר תוויות, יש לבצע ארגון של bazelbuild.

בקשות משיכה

  1. מסננים את רשימת בקשות השליפה לפי תווית הצוות.
  2. בדיקה של בקשות משיכה פתוחות.
    1. אופציונלי: אם הוקצה לך ביקורת אבל היא לא מתאימה לך, יש להקצות מחדש את כותב הביקורת המתאים כדי לבצע בדיקת קוד.
  3. יש לעבוד עם יוצר בקשת המשיכה כדי להשלים בדיקת קוד.
  4. עליך לאשר את יחסי הציבור.
  5. מוודאים שכל הבדיקות עוברות.
  6. מייבאים את התיקון למערכת הפנימית לניהול גרסאות ומפעילים את הגשות הפנימיות.
  7. שולחים את התיקון הפנימי. אם התיקון יישלח וייוצא, ה-PR ייסגר באופן אוטומטי על ידי GitHub.

עדיפות

ההגדרות הבאות בעדיפות גבוהה ישמשו את השומרים כדי לסנן בעיות.

  • P0 – פונקציונליות מהותית הפגומה, שבגללה אין אפשרות להשתמש בגרסה של Bazel (פחות אפשרויות הפצה) או ששירות שהושבת באופן משמעותי משפיע לרעה על פיתוח הפרויקט של Bazel. זה כולל רגרסיות שהושקו בגרסה חדשה שחוסמות מספר משמעותי של משתמשים, או שינוי תוכנה לא תואם שלא עמד בדרישות של מדיניות המעבר. אין פתרון מעשי.
  • P1 – תכונה קריטית או בעיה שיש לטפל בה בגרסה הבאה, או בעיה חמורה שמשפיעה על משתמשים רבים (כולל פיתוח הפרויקט של Bazel), אבל קיימת פתרון מעשי. בדרך כלל לא נדרשת פעולה מיידית. בביקוש גבוה ומתוכנן במפת הדרכים הנוכחית של הרבעון הנוכחי&#39.
  • P2 – פגם או תכונה שצריך לטפל בה, אבל אנחנו לא עובדים כרגע. גרסה פעילה בגרסת
  • P3 – תיקון באגים קטן או שיפור רצוי עם השפעה קלה. לא ניתנת עדיפות למפות מפות של Bazel או למהדורה עתידית כלשהי, אך מומלץ להוסיף תוכן מהקהילה.
  • P4 – פגם בעדיפות נמוכה או בקשה לתכונה שלא צפויה להיסגר. אפשר גם להשאיר אותם פתוחים לעדיפות עתידית אם יש השפעה על משתמשים נוספים.
  • קופסת קרח
    • יש לנו בעיות ואין לנו כרגע זמן לטפל בהן או לא לאשר אותן. אנחנו נסגור את הבעיות האלה כדי לציין שאף אחד לא עובד עליהן, אבל נמשיך לעקוב אחר החוקיות שלהן במשך הזמן ונחזיר אותן לפעילות אם מספיק אנשים יפגעו ואם יהיו לנו משאבים להתמודד איתם. כמו תמיד, אתם יכולים להגיב או להוסיף תגובות לבעיות האלה, גם אם הן סגורות.

תוויות של קבוצות

עקב בעיות חדשות, הוצאנו משימוש את התוויות category: * לטובת תוויות הצוות.

כאן מופיעה רשימת התוויות המלאה.