Bug triage/he

עזרה למיזם גרמפס מיון/ברירה/סיווג תקלים וסוגיות (Bug triage).

טיפול בתקל מתחיל תמיד ביכולת לשחזור אותו, לא מעט פעמים המפתח לא מצליח לשחזר תקל ולכן בהכרך לא יצליח לטפל בו. מטרת סיווג התקלים היא לאפשר בדיוק את זה.

מערכת מעקב תקלים/סוגיות של גרמפס מנוהל באתר הבא: https://gramps-project.org/bugs

מעונינים להתנדב? יש לקרוא עמוד זה ואז ליצור קשר עם פורום המפתחים של גרמפס ולבקש יכולת לשנות דיווחי תקלים

מטרות סיווג התקלים

מה

מטרת סיווג תקלים היא להקל על מפתחים לבצע תיקוני תקלים ופיתוח על־ידי ארגון רשימת התקלים עבורם. משמעות הדבר הוא שמפתחים ישקיעו פחות זמן בשאלות הבהרה למדווחי תקלים כדי להבין את הבעיה בנסין לשחזר אותה ולאשר אם היא עדיין קיימת בענף master העדכני ב־Git.

סיווג תקלים כולל צמצום כמות כרטיסי/דיווחי תקל פתוחים, הסרת כרטיסים שהתיישנו או שתוקפם פג, וקיבוץ בקשות לשנויים ותוספות תכונה.

מה עושים ב־Bug Triage בפועל?

1. שחזור: נסיון לשחזר את התקל לפי השלבים שדווחו.
2. השלמת מידע חסר: גרסת תוכנה, מערכת הפעלה, יומן שגיאות (log), נתוני דוגמה, צילומי מסך, שלבי פעולה מדויקים.
3. אימות: בדיקה אם התקל עדיין קורה בגרסה עדכנית (או שכבר תוקן)

איך

מצבי Status תקינים ב־MantisBT.
* "new"
* "feedback"
* "acknowledged"
* "confirmed"
* "assigned"
* "closed"
* "resolved"

עבודת הכנה

כשלב מקדים יש להכין סביבת בדיקות שכוללת התקנה נקייה של גרמפס וקובץ נתוני הדוגמה. יש לוודא שנעשה שימוש בגרסה העדכנית 6.0.8 של גרמפס; לרוב מומלץ לעבוד גם עם ענף master ב־Git. לאחר ההתקנה יש ליצור אילן־יוחסין חדש ולייבא את קובץ נתוני הדוגמה example.gramps.

כדאי לעיין בתיעוד MantisBT ולהכיר את קודי התחביר של MantisBT שנתמכים.

סדר עבודת הסיווג (טריאז’)

1. בחירה בכרטיס – פתיחה ובדיקה של כרטיס שמצוי במצב "new".
2. איסוף מידע – ריכוז המידע שדרוש לשחזור: צעדי שחזור, תוצאה צפויה לעומת התוצאה בפועל, גרסת גרמפס, סוג וגרסת מערכת ההפעלה, יומנים (logs) והודעת שגיאה/traceback.
3. ניסיון שחזור – ביצוע ניסיון שחזור בסביבה נקייה (עדיפות: עם example.gramps או עם מקרה מבחן מזערי).
   • אם במהלך ניסיון השחזור התגלה תקל אחר, יש לפתוח כרטיס חדש עבור התקל החדש ולציין קשר בין הכרטיסים.
4. קביעה אם התקל שוחזר – החלטה אם התקל שוחזר, ובהתאם המשך טיפול:

אם התקל שוחזר

1. בדיקות נלוות
   1. שיפור הכרטיס – כותרת מדויקת, תיאור ברור, וסדר צעדי שחזור שאפשר לבצע במדויק.
   2. תיחום התקל – זיהוי רכיב/פרקן/פונקציה/נסיבות שמפעילים את התקל.
   3. בדיקת תקפות – בחינת נחיצות הדיווח: האם הכרטיס תקף, האם הוא כפילות, והאם מדובר בגרסה נתמכת.
2. סיווג וארגון הכרטיס – בדיקה אם המידע מספק, אם המיזם מתאים, ואם מדובר בתקל או בבקשת תכונה/שיפור.
3. עדכון מצב (Status)
   1. "acknowledged" – הדיווח אינו ספאם ויש בו בסיס לפתיחת בדיקה.
   2. "confirmed" – התקל שוחזר או אומת בידי אחרים.
   3. "assigned" – מתבצעת עבודה פעילה על התקל (אם העבודה הופסקה, יש להסיר מצב זה).
4. תיעוד מסייע למפתחים – צירוף יומנים/traceback רלוונטיים, צמצום למקרה מבחן מזערי, והפניה לניסיונות טיפול קודמים (כולל קישורים ל־PR אם קיימים).
5. סגירה/פתרון
   1. "resolved" – התקל תוקן (רצוי לציין SHA/commit hash).
   2. "closed" – הכרטיס נסגר בצירוף נימוק (לא רלוונטי/כפילות/לא ישים/גרסה לא נתמכת).

אם התקל לא שוחזר

1. אם חסר מידע מהותי, יש לקבוע מצב "feedback" ולפנות למדווח בבקשה להשלמות והבהרות.
2. אם לאחר בדיקה מסתבר שהתקל אינו קיים עוד ב־6.0.8/master או שאינו ישים, יש לסגור את הכרטיס בצירוף נימוק.

הערה: "נמצא תקל חדש" משמעו שתקל אחר התגלה במהלך ניסיון שחזור התקל המקורי; במקרה כזה יש להגיש כרטיס ייעודי לתקל החדש ולציין קשר בין הכרטיסים.

מיזמים נתמכים וטיפול בכרטיסים בגרסאות ישנות

נכון לעכשיו נתמכים רק המיזמים Gramps 5.2, Gramps 6.0 ו־Gramps master. לכן כרטיסים שנותרו פתוחים בגרסאות שאינן נתמכות צריכים להיסגר או להיות מועברים/מעודכנים בהתאם:

• ניתן לסמן "resolved" באופן זמני, אם התקל כבר אינו ניתן לבחינה בגרסה נתמכת.
• אם התקל אינו ישים עוד, יש לשנות מצב ל־"closed" ולנמק.
• אם מדובר בגרסה שהגיעה לסוף חייה (EOL), יש לבצע גיבוי אילנות־יוחסין ולהתקין גרסה נתמכת לצורך בדיקה.
  • לקריאה נוספת: גרסאות קודמות של גרמפס
• אם התקל עדיין קיים, יש להעביר את הכרטיס למיזם הנכון (לדוגמה: תקל לעומת בקשת תכונה).
• אם חסר מידע, יש לבקש מהמדווח "feedback".
• אם הכרטיס כולל כמה סוגיות, יש לצמצם אותו לסוגיה אחת, ולבקש לפתוח כרטיסים נפרדים עבור השאר.
• במקרה של סוגיות אחרות, יש לבחור דרך טיפול מתאימה ולנמק.

יש להקפיד תמיד לנהוג בנימוס בעת מענה לדיווח תקל.

עקרונות עבודה משלימים

• במיזמים הנתמכים יש להשלים סיווג: לסגור כפילויות ("closed"), לחדד כותרות, ולהוסיף מידע שמאפשר שחזור — במיוחד באמצעות קובץ נתוני הדגמה של גרמפס — שכן שחזור הוא נקודת המוצא לתיקון.
• במיזם בקשות תכונה חדשה (Feature Requests) ארגון דיווחים: לאחד כפילויות, לשפר כותרות, ולבקש ניסוח מפורט כאשר הבקשה אינה ברורה דיה (לנהוג בנימוס).
• לא להשאיר כרטיסים במצב "new" לאחר שבוצעה בדיקה ראשונית.
• אם הדוח/כרטיס ממתין לקלט מהמדווח או מגורם אחר, יש לסמן "feedback".
• אם מפתח הקצה לעצמו את הסוגיה והוגשה בקשת משיכה (Pull Request) תואמת, יש לוודא שה־PR כולל הפניה לכרטיס MantisBT, בהתאם למדיניות הקיבוע (commit) ולשילוב מעקב תקלים עבור Pull Request.

פתרון תקלים עבור מפתחים

מידע זה מיועד למפתחים שמבצעים מעקב אחרי הסוגיות שהוגשו.

עמוד Roadmap בעמעקב התקלים מציג את התקלים שכרגע נמצאות בעדיפות לגרסאות הבאות. אם מחפשים תקל לתיקון, זה מקום טוב להתחיל. מיקום ב־Roadmap נשלט על־ידי השדה "Target Version" בתקל. גרסאות מדומות מיוחדות מסוג "X.Y.99", כגון "3.4.99" ו־"4.0.99", מציגות תקלים שהיינו רוצים לתקן בסופו של דבר עבור גרסת "X.Y", אך עדיין לא ידוע מועד יעד מדויק. תקלים שאמורים לעכב שחרור גרסה אמורות להופיע ב־Roadmap תחת מספר גרסה אמיתי, ויש להזיז אותן רק לאחר מתן נימוק או הודעה מראש ברשימת המפתחים [1]. אם מתקנים תקל שתוזמן ליעד מאוחר יותר לפני ששוחרר יעד מוקדם יותר, יש לעדכן ידנית את שדה יעד השחרור (target release) לפני סימון התקל כ־resolved, אחרת התצוגה ב־Roadmap לא תהיה מדויקת [2].

באופן כללי, בעת פתרון סוגיה, כדאי תמיד להוסיף הערה עם “commit hash” (נקרא גם Git commit “reference” או “SHA”) של ההתחייבות (commit) שתיקנה את הבעיה.

בעת פתרון סוגיות בענף תחזוקה (maintenance branch), יש תמיד להגדיר את השדה "Fixed in version" לגרסת השחרור הבאה שתיווצר מאותו ענף. כך הסוגיה תופיע באופן נכון בעמוד Change Log עבור אותו מיזם.

תקלים במיזמי ענפי תחזוקה לא אמורות להיות מסומנות כ־"resolved" עד שהמפתח התחייב (committed) את השינוי לענף התחזוקה המתאים. בנוסף, באחריות המפתח לוודא שהשינוי מוזג גם לענף master.

הרשאות MantisBT

כאשר אין הרשאות מספיקות ב־MantisBT (היכולת לשנות מצב תקל מ־"new" ל־"feedback", "acknowledged", "confirmed", "closed" או "resolved"), אפשר לבקש בפורום מפתחי גרמפס שמישהו אחר עם הרשאות מתאימות ישנה את מצב התקל למצב הרצוי (לדוגמה: "Could someone set bug #1 to "closed" please?). לאחר שעושים זאת מספיק פעמים, אפשר לבקש מתן הרשאות מתאימות MantisBT באותו אזור של פורום המפתחים.

מצב

עמוד סיכום מצב תקלים:

• https://gramps-project.org/bugs/summary_page.php

לתשומת לב, בעבר נעלמו 4495 סוגיות במהלך שדרוג מסד נתונים של MantisBT למרבה הצער, מספר סוגיות קיימות במערכת ממשיכות להפנות לסוגיות אבודות אלו.

סוגיות

עם MantisBT:

• 0012273 "Bugtracker" יצירת פרופיל הרשאות ייעודי לאנשים שתפקידם הוא סיווג בלבד

מידע נוסף

• כיצד ליצור דוח תקל טוב
• סוגיות ידועות
• בעיות נפוצות