commit 384cf23c6ed05e1f151032958a2cc2bb8100344b (HEAD, refs/remotes/origin/master) Author: Andrew Hyatt Date: Sat Jan 9 00:14:03 2016 -0500 Adding example replies to bug-triage. * admin/notes/bug-triage: Added example replies. Also, as requested, making the process notes into more of a checklist. diff --git a/admin/notes/bug-triage b/admin/notes/bug-triage index 5b0e35c..7392fb9 100644 --- a/admin/notes/bug-triage +++ b/admin/notes/bug-triage @@ -16,29 +16,63 @@ the ones that are not reproducible on the current release. serious, important, or normal. 2. This will also show closed bugs that have yet to be archived. You can filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress). - 3. For each bug, do the following: - - Read the mail thread for the bug. Find out if anyone has been able to - reproduce this on the current release. - - If someone has been able to, then your work is finished for this bug. - - Make sure there's enough information to reproduce the bug. It should be - very clear how to reproduce. If not, please ask for specific steps to - reproduce. If you don't get them, and you can't reproduce without them, - you can close as "doneunreproducible". - - If no one has mentioned being able to reproduce on the current release, - read the bug description and attempt to reproduce on an emacs started - with "emacs -Q" (the goal is to not let our personal configs interfere - with bug testing). - - If you can reproduce, then reply on the thread (either on the original - message, or anywhere you find appropriate) that you can reproduce this on - the current release. If your reproduction gives additional info (such as - a backtrace), then add that as well, since it will help whoever attempts - to fix it. - - If you can't reproduce, state that you can't reproduce it on the current - release, ask if they can try again against the current release. Tag the - bug as "unreproducable". Wait a few weeks for their reply - if they can - reproduce it, then that's great, otherwise close as "doneunreproducible". - - If the bug ends up still open, make sure the priority and other tags - seems reasonable. + 3. For each bug, we want to primarily make sure it is still + reproducible. A bug can and should stay open as long as it is + still a bug and no one has fixed it. The following is a + suggested checklist to follow for handling these bugs, along with + example replies. The various closings, taggings, etc, are done + with debbugs control messages, which in debbugs-gnu is initiated + with a "C". + [ ] Read the mail thread for the bug. Find out if anyone has + been able to reproduce this on the current release. If + someone has been able to, then your work is finished for this + bug. + [ ] Make sure there's enough information to reproduce the bug. + It should be very clear how to reproduce. If not, please ask + for specific steps to reproduce. If you don't get them, and + you can't reproduce without them, you can close as + "doneunreproducible". Sometimes there is specific hardware + involved, such as particular models of keyboards, or it may + simply involve a platform you don't have access to. It's + fine to ignore those, and let a future triager that is better + equipped to reproduce it handle it. + + An example reply asking for clear reproduction steps would be + something like: "Hi! In the interest of seeing whether this + is reproducible, and to aid anyone who will look at this bug + in the future, can you please give instructions on how to + reproduce this bug starting from an emacs without + configuration ("emacs -Q")? + [ ] If there is enough detail to reproduce, but no one has + mentioned being able to reproduce on the current release, + read the bug description and attempt to reproduce on an emacs + started with "emacs -Q" (the goal is to not let our personal + configs interfere with bug testing). + + If you can reproduce, then reply on the thread (either on the + original message, or anywhere you find appropriate) that you + can reproduce this on the current release. If your + reproduction gives additional info (such as a backtrace), + then add that as well, since it will help whoever attempts to + fix it. + + Example reply: "I'd just like to add that I can reproduce + this on the latest version of Emacs, Emacs 25." + + If you can't reproduce, state that you can't reproduce it on + the current release, ask if they can try again against the + current release. Tag the bug as "unreproducable". Wait a + few weeks for their reply - if they can reproduce it, then + that's great, otherwise close as "doneunreproducible". + + Example reply: "I've attempted to reproduce this on the + latest version of emacs, Emacs 25, but haven't been able to. + Can you try to reproduce this on this version, and let us + know if you are able to? If I don't hear back in a few + weeks, I'll just close this bug as unreproducible." + [ ] Check that the priority is reasonable. Most bugs should be + marked as normal, but crashers and security issues can be + marked as "severe". 4. Your changes will take some time to take effect. After a period of minutes to hours, you will get a mail telling you the control message has been processed. At this point, if there were no errors detected, you and commit 33715e54e3aa9d056ddc207d052e0f260aa9f6a7 Author: Andrew Hyatt Date: Fri Jan 8 23:04:59 2016 -0500 Rename the notes/admin/triage file to bug-triage. * CONTRIBUTE: Change reference to the triage file name. * admin/notes/triage: Rename file to admin/notes/bug-triage. diff --git a/CONTRIBUTE b/CONTRIBUTE index 177a38c..19ec682 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -233,7 +233,7 @@ is still reproducible. The process of going through old or new bugs and acting on them is called bug triage. This process is described in the file -admin/notes/triage. +admin/notes/bug-triage. ** Document your changes. diff --git a/admin/notes/bug-triage b/admin/notes/bug-triage new file mode 100644 index 0000000..5b0e35c --- /dev/null +++ b/admin/notes/bug-triage @@ -0,0 +1,68 @@ +HOW TO TRIAGE EMACS BUGS -*- outline -*- + +This document just describes the procedure of triaging bugs, for information on +how to work with the bug tracker, see the bugtracker file in this same directory +for the basics. You can also install the debbugs ELPA package for access to M-x +debbugs-gnu, an emacs interface to debbugs, and M-x debbugs-org, an emacs +interface via org-mode. + +* Bug backlog triage procedure + +The goal of this triage is to prune down the list of old bugs, closing +the ones that are not reproducible on the current release. + + 1. To start, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the + web browser), and accept the default list option of bugs that have severity + serious, important, or normal. + 2. This will also show closed bugs that have yet to be archived. You can + filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress). + 3. For each bug, do the following: + - Read the mail thread for the bug. Find out if anyone has been able to + reproduce this on the current release. + - If someone has been able to, then your work is finished for this bug. + - Make sure there's enough information to reproduce the bug. It should be + very clear how to reproduce. If not, please ask for specific steps to + reproduce. If you don't get them, and you can't reproduce without them, + you can close as "doneunreproducible". + - If no one has mentioned being able to reproduce on the current release, + read the bug description and attempt to reproduce on an emacs started + with "emacs -Q" (the goal is to not let our personal configs interfere + with bug testing). + - If you can reproduce, then reply on the thread (either on the original + message, or anywhere you find appropriate) that you can reproduce this on + the current release. If your reproduction gives additional info (such as + a backtrace), then add that as well, since it will help whoever attempts + to fix it. + - If you can't reproduce, state that you can't reproduce it on the current + release, ask if they can try again against the current release. Tag the + bug as "unreproducable". Wait a few weeks for their reply - if they can + reproduce it, then that's great, otherwise close as "doneunreproducible". + - If the bug ends up still open, make sure the priority and other tags + seems reasonable. + 4. Your changes will take some time to take effect. After a period of minutes + to hours, you will get a mail telling you the control message has been + processed. At this point, if there were no errors detected, you and + everyone else can see your changes. If there are errors, read the error + text - if you need help, consulting the bugtracker documentation in this + same directory. + +* New bug triage process + +The goal of the new bug triage process is similar to the backlog triage process, +except that the focus is on prioritizing the bug, and making sure it is has +necessary information for others to act on. + +For each new bug, ask the following questions: + + 1. Is the bug report written in a way to be easy to reproduce (starts from + emacs -Q, etc.)? If not, ask the reporter to try and reproduce it on an + emacs without customization. + 2. Is the bug report written against the latest emacs? If not, try to + reproduce on the latest version, and if it can't be reproduced, ask the + reporter to try again with the latest version. + 3. Is the bug the same as another bug? If so, merge the bugs. + 4. What is the priority of the bug? Add a priority: critical, grave, serious, + important, normal, minor, or wishlist. + 5. Who should be the owner? This depends on what component the bug is part + of. You can look at the admin/MAINTAINERS file (then you can just search + emacs-devel to match the name with an email address). diff --git a/admin/notes/triage b/admin/notes/triage deleted file mode 100644 index 5b0e35c..0000000 --- a/admin/notes/triage +++ /dev/null @@ -1,68 +0,0 @@ -HOW TO TRIAGE EMACS BUGS -*- outline -*- - -This document just describes the procedure of triaging bugs, for information on -how to work with the bug tracker, see the bugtracker file in this same directory -for the basics. You can also install the debbugs ELPA package for access to M-x -debbugs-gnu, an emacs interface to debbugs, and M-x debbugs-org, an emacs -interface via org-mode. - -* Bug backlog triage procedure - -The goal of this triage is to prune down the list of old bugs, closing -the ones that are not reproducible on the current release. - - 1. To start, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the - web browser), and accept the default list option of bugs that have severity - serious, important, or normal. - 2. This will also show closed bugs that have yet to be archived. You can - filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress). - 3. For each bug, do the following: - - Read the mail thread for the bug. Find out if anyone has been able to - reproduce this on the current release. - - If someone has been able to, then your work is finished for this bug. - - Make sure there's enough information to reproduce the bug. It should be - very clear how to reproduce. If not, please ask for specific steps to - reproduce. If you don't get them, and you can't reproduce without them, - you can close as "doneunreproducible". - - If no one has mentioned being able to reproduce on the current release, - read the bug description and attempt to reproduce on an emacs started - with "emacs -Q" (the goal is to not let our personal configs interfere - with bug testing). - - If you can reproduce, then reply on the thread (either on the original - message, or anywhere you find appropriate) that you can reproduce this on - the current release. If your reproduction gives additional info (such as - a backtrace), then add that as well, since it will help whoever attempts - to fix it. - - If you can't reproduce, state that you can't reproduce it on the current - release, ask if they can try again against the current release. Tag the - bug as "unreproducable". Wait a few weeks for their reply - if they can - reproduce it, then that's great, otherwise close as "doneunreproducible". - - If the bug ends up still open, make sure the priority and other tags - seems reasonable. - 4. Your changes will take some time to take effect. After a period of minutes - to hours, you will get a mail telling you the control message has been - processed. At this point, if there were no errors detected, you and - everyone else can see your changes. If there are errors, read the error - text - if you need help, consulting the bugtracker documentation in this - same directory. - -* New bug triage process - -The goal of the new bug triage process is similar to the backlog triage process, -except that the focus is on prioritizing the bug, and making sure it is has -necessary information for others to act on. - -For each new bug, ask the following questions: - - 1. Is the bug report written in a way to be easy to reproduce (starts from - emacs -Q, etc.)? If not, ask the reporter to try and reproduce it on an - emacs without customization. - 2. Is the bug report written against the latest emacs? If not, try to - reproduce on the latest version, and if it can't be reproduced, ask the - reporter to try again with the latest version. - 3. Is the bug the same as another bug? If so, merge the bugs. - 4. What is the priority of the bug? Add a priority: critical, grave, serious, - important, normal, minor, or wishlist. - 5. Who should be the owner? This depends on what component the bug is part - of. You can look at the admin/MAINTAINERS file (then you can just search - emacs-devel to match the name with an email address). commit f36805424633e3acb48ed9f0f729a36760e4cb7f Merge: bc9a28a 4580671 Author: K. Handa Date: Fri Jan 8 23:21:43 2016 +0900 Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs commit bc9a28ab424647209cc2f91ad21cdb41a7052812 Author: K. Handa Date: Fri Jan 8 23:21:15 2016 +0900 Fix outdated comments. diff --git a/src/fontset.c b/src/fontset.c index 9429d79..0f89b71 100644 --- a/src/fontset.c +++ b/src/fontset.c @@ -63,17 +63,26 @@ along with GNU Emacs. If not, see . */ An element of a base fontset is a vector of FONT-DEFs which themselves are vectors of the form [ FONT-SPEC ENCODING REPERTORY ]. - An element of a realized fontset is nil, t, 0, or a vector of this - form: + An element of a realized fontset is nil, t, 0, or a cons that has + this from: - [ PREFERRED-RFONT-DEF RFONT-DEF0 RFONT-DEF1 ... ] + (CHARSET-ORDERED-LIST-TICK . FONT-GROUP) + + CHARSET_ORDERED_LIST_TICK is the same as charset_ordered_list_tick or -1. + + FONT-GROUP is a vector of elements that have this form: + + [ RFONT-DEF0 RFONT-DEF1 ... ] Each RFONT-DEFn (i.e. Realized FONT-DEF) has this form: [ FACE-ID FONT-DEF FONT-OBJECT SORTING-SCORE ] - RFONT-DEFn are automatically reordered by the current charset - priority list. + RFONT-DEFn are automatically reordered considering the current + charset priority list, the current language environment, and + priorities determined by font-backends. + + RFONT-DEFn may not be a vector in the following cases. The value nil means that we have not yet generated the above vector from the base of the fontset. @@ -83,7 +92,7 @@ along with GNU Emacs. If not, see . */ The value 0 means that no font is available for the corresponding range of characters in this fontset, but may be available in the - default fontset. + fallback font-group or in the default fontset. A fontset has 8 extra slots. @@ -407,6 +416,9 @@ reorder_font_vector (Lisp_Object font_group, struct font *font) if (! NILP (encoding)) { + /* This spec specifies an encoding by a charset set + name. Reflect the preference order of that charset + in the upper bits of SCORE. */ Lisp_Object tail; for (tail = Vcharset_ordered_list; @@ -419,6 +431,10 @@ reorder_font_vector (Lisp_Object font_group, struct font *font) } else { + /* This spec does not specify an encoding. If the spec + specifies a language, and the language is not for the + current language environment, make the score + larger. */ Lisp_Object lang = Ffont_get (font_spec, QClang); if (! NILP (lang) @@ -442,11 +458,11 @@ reorder_font_vector (Lisp_Object font_group, struct font *font) XSETCAR (font_group, make_number (low_tick_bits)); } -/* Return a font-group (actually a cons (-1 . FONT-GROUP-VECTOR)) for - character C in FONTSET. If C is -1, return a fallback font-group. - If C is not -1, the value may be Qt (FONTSET doesn't have a font - for C even in the fallback group), or 0 (a font for C may be found - only in the fallback group). */ +/* Return a font-group (actually a cons (CHARSET_ORDERED_LIST_TICK + . FONT-GROUP)) for character C or a fallback font-group in the + realized fontset FONTSET. The elements of FONT-GROUP are + RFONT-DEFs. The value may not be a cons. See the comment at the + head of this file for the detail of the return value. */ static Lisp_Object fontset_get_font_group (Lisp_Object fontset, int c) @@ -461,23 +477,37 @@ fontset_get_font_group (Lisp_Object fontset, int c) else font_group = FONTSET_FALLBACK (fontset); if (! NILP (font_group)) + /* We have already realized FONT-DEFs of this font group for C or + for fallback (FONT_GROUP is a cons), or we have already found + that no appropriate font was found (FONT_GROUP is t or 0). */ return font_group; base_fontset = FONTSET_BASE (fontset); if (NILP (base_fontset)) + /* Actually we never come here because FONTSET is a realized one, + and thus it should have a base. */ font_group = Qnil; else if (c >= 0) font_group = char_table_ref_and_range (base_fontset, c, &from, &to); else font_group = FONTSET_FALLBACK (base_fontset); + + /* FONT_GROUP not being a vector means that no fonts are specified + for C, or the fontset does not have fallback fonts. */ if (NILP (font_group)) { font_group = make_number (0); if (c >= 0) + /* Record that FONTSET does not specify fonts for C. As + there's a possiblity that a font is found in a fallback + font group, we set 0 at the moment. */ char_table_set_range (fontset, from, to, font_group); return font_group; } if (!VECTORP (font_group)) return font_group; + + /* Now realize FONT-DEFs of this font group, and update the realized + fontset FONTSET. */ font_group = Fcopy_sequence (font_group); for (i = 0; i < ASIZE (font_group); i++) if (! NILP (AREF (font_group, i))) @@ -498,21 +528,21 @@ fontset_get_font_group (Lisp_Object fontset, int c) } /* Return RFONT-DEF (vector) in the realized fontset FONTSET for the - character C. If no font is found, return Qnil if there's a + character C. If no font is found, return Qnil or 0 if there's a possibility that the default fontset or the fallback font groups have a proper font, and return Qt if not. If a font is found but is not yet opened, open it (if FACE is not NULL) or return Qnil (if FACE is NULL). - ID is a charset-id that must be preferred, or -1 meaning no + CHARSET_ID is a charset-id that must be preferred, or -1 meaning no preference. If FALLBACK, search only fallback fonts. */ static Lisp_Object -fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, - bool fallback) +fontset_find_font (Lisp_Object fontset, int c, struct face *face, + int charset_id, bool fallback) { Lisp_Object vec, font_group; int i, charset_matched = 0, found_index; @@ -534,8 +564,8 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, /* We have just created the font-group, or the charset priorities were changed. */ reorder_font_vector (font_group, face->ascii_face->font); - if (id >= 0) - /* Find a spec matching with the charset ID to try at + if (charset_id >= 0) + /* Find a spec matching with CHARSET_ID to try it at first. */ for (i = 0; i < ASIZE (vec); i++) { @@ -546,7 +576,7 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, break; repertory = FONT_DEF_REPERTORY (RFONT_DEF_FONT_DEF (rfont_def)); - if (XINT (repertory) == id) + if (XINT (repertory) == charset_id) { charset_matched = i; break; @@ -554,7 +584,9 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, } } - /* Find the first available font in the vector of RFONT-DEF. */ + /* Find the first available font in the vector of RFONT-DEF. If + CHARSET_MATCHED > 0, try the correspoing RFONT-DEF first, then + try the rest. */ for (i = 0; i < ASIZE (vec); i++) { Lisp_Object font_def; @@ -565,13 +597,13 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, { if (charset_matched > 0) { - /* Try the element matching with the charset ID at first. */ + /* Try the element matching with CHARSET_ID at first. */ found_index = charset_matched; /* Make this negative so that we don't come here in the next loop. */ charset_matched = - charset_matched; /* We must try the first element in the next loop. */ - i--; + i = -1; } } else if (i == - charset_matched) @@ -630,10 +662,10 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, if (NILP (font_object)) { /* Something strange happened, perhaps because of a - Font-backend problem. Too avoid crashing, record + Font-backend problem. To avoid crashing, record that this spec is unusable. It may be better to find another font of the same spec, but currently we don't - have such an API. */ + have such an API in font-backend. */ RFONT_DEF_SET_FACE (rfont_def, -1); continue; } @@ -693,6 +725,7 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, i = found_index; } + /* Record that no font in this font group supports C. */ FONTSET_SET (fontset, make_number (c), make_number (0)); return Qnil; @@ -711,6 +744,9 @@ fontset_find_font (Lisp_Object fontset, int c, struct face *face, int id, } +/* Return RFONT-DEF (vector) corresponding to the font for character + C. The value is not a vector if no font is found for C. */ + static Lisp_Object fontset_font (Lisp_Object fontset, int c, struct face *face, int id) {