Bugzilla changes/improvements
Hello koha-devel, I'm doing a checking of our bugzilla usage. I've added some pages on the wiki about submitting a patch, and have some questions/propositions. Please give me your opinion about them. The propositions that won't be agreed by all (unanimity) will be discussed in a later IRC meeting. Here they are, in random order. • what's the difference between master and Rel_3_8 versions ? I feel "master" should not be used for bugs, only for ENH, and, when a patch is submitted for an ENH, it should be attached to "next planned version" (ie : Rel_3_8 those days) • The priority is used to set "patch sent". This is a problem as we completly loose Priority field usage. A solution would be to have a patch status "patch sent" added, have the patch status always visible, and keep priority for what it's supposed to be, the priority. Patch status could then be "--" (patch not sent), "needs signoff", "does not apply"... as we have today. • QA contact : could we do a better use of this field ? I know Ian & QA team are working/thinking to this question, so it's here just for reminder. • Signed-off & passed QA = The signature and the QA process could be in any order: if a patch does not meet our QA rules, there's no need to test it if the QA team sees it. So maybe we have a field for "QA status" (-- / passed QA / failed) and the patch status for sign-off (-- / signed off / does not apply) • For instance, I don't know how we could keep track of the "patch submitter" ? do we want/need ? I throw an open question here. • bug status : it's NEW/ASSIGNED/RESOLVED and it's not really correctly used. Many bugs stay "new" = as of today, 12 bugs have a patch for version Rel_3_8 and are still marked "new". They should be "assigned". I propose to enforce the use of the "ASSIGNED". This question is connected to the question of the use of the default assignee i've asked a few weeks ago. • Components : I proposed to clean them a while ago. Now I have concrete & detailled propositions. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap I've checked all entries with less than 30 bugs open, and propose something for each of them. The global idea is to have component entries close from modules we have in Koha. ∘ About, importedbugs, = no bugs, drop those entries. ∘ Authentication = 19 bugs, move them to "architecture, Internals and plumbing" ∘ Browser compatibility = 10 bugs, move them to "Architecture internals and plumbing" or "templates" ∘ bugs.koha-community.org = 2 bugs, move them to "websites, mailing lists,..." ∘ contribs.koha-community.org = 1 bug, move it to "websites, mailing lists,..." ∘ Developer documentation = 5 bugs, move them to "Architecture, internals and plumbing" ∘ Documentation = 11 bugs, keep them here, interesting for Nicole & doc writers ∘ Holidays = 2 bugs, move them to "Tools" ∘ Installation and upgrade = merge "command line" and "web-based" (20 and 24 repectively) ∘ Label printing = 27 bugs, move them to "Tools" ∘ MARC authority and MARC bibliographic (26 and 27 repectively) = we could merge them, not sure, i'm not proposing that, your opinion/thoughts about that ? ∘ MARC bibliographic staging/import = 14 bugs, move them to tools ∘ Self-checkout = 4, move them to "circulation" ∘ SIP2 = 18, move them to "circulation" or "Architecture, plumbing" ∘ Test suite = only 3, but keep them as we want to improve test coverage, it's to encourage ppl ! ∘ Transaction logs = 5, move them to "Tools" ∘ translate.koha-community.org = 2, move them to "Websites, Mailing lists,..." ∘ Z39.50, SRU, OpenSearch = 14, move them to searching • The "hardware" field is useless. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=rep_platform&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap 12 are reported "MacIntosh", and not related to Mac specifically, others are PC/All/Other. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?) • The 'OS' field is useless. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=op_sys&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap ∘ 5 bugs are "windows", and 3 are "others", it does not seem they are relevant. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?) • Version field : there are many, only a few are used : http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap Could we hide all versions that are unsupported and have no bug opened now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
• The priority is used to set "patch sent". This is a problem as we completly lose Priority field usage.
I don't mind that we lose Priority. Priority is completely arbitrary: a bug which is high priority for me might not be high priority for the release manager. I ignore this setting altogether.
I propose to enforce the use of the "ASSIGNED".
What do you mean by "enforce?" I reset the status to "ASSIGNED" whenever I see a bug which seems to be so. There's not much we can do besides point out the error. This question is connected to the
question of the use of the default assignee i've asked a few weeks ago.
• Components : I proposed to clean them a while ago. Now I have concrete & detailled propositions.
I really don't see any problem with having lots of components. In fact I'd vote for more rather than fewer.
• The "hardware" field is useless.
It isn't if you have a bug which is tied to your particular hardware. If it's useless it's probably because people don't remember to set it. Can we force it to default to "Any" since most bugs are not hardware-dependent?
• The 'OS' field is useless.
Same as hardware: seldom-used, but maybe not useless. Can they be hidden when "advanced fields" are hidden?
Could we hide all versions that are unsupported and have no bug opened now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions)
Can Bugzilla be configured to show only a selection of versions for which there are bugs? I'm in favor of this change if so. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Oh, and my vote for the most urgently-needed change to Bugzilla? Please change "Rel_3_8" to "rel_3_8" like all the other "rel_*_*" entries, it's driving me crazy!! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Le 24/10/2011 18:20, Owen Leonard a écrit :
Oh, and my vote for the most urgently-needed change to Bugzilla?
Please change "Rel_3_8" to "rel_3_8" like all the other "rel_*_*" entries, it's driving me crazy!! Agreed, I saw this small-but-very-annoying detail today, but can't change it yet (no access) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 24/10/2011 18:20, Owen Leonard a écrit :
Oh, and my vote for the most urgently-needed change to Bugzilla?
Please change "Rel_3_8" to "rel_3_8" like all the other "rel_*_*" entries, it's driving me crazy!!
(Thanks to chris that gave me access) It's done. I also have moved all rel_3_8 bugs : * to master, for ENH * to rel_3_6 for the 4 bugs that have been reported against rel_3_8 HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 24/10/2011 18:12, Owen Leonard a écrit : >> • The priority is used to set "patch sent". This is a problem as we >> completly lose Priority field usage. > > I don't mind that we lose Priority. Priority is completely arbitrary: > a bug which is high priority for me might not be high priority for the > release manager. I ignore this setting altogether. My arguments: * having "patch sent" in priority is not really intuitive * having it in the "patch status" is logic * we could completly discard priority if no-one want to use it. But I feel we could use it to set a priority as a supplementary information (with the severity) : a bug can be critical, but happening only in a very rare situation (low priority), or not very important, but annoying everyday ! So I think both fields can be usefull. >> I propose >> to enforce the use of the "ASSIGNED". > > What do you mean by "enforce?" I reset the status to "ASSIGNED" > whenever I see a bug which seems to be so. There's not much we can do > besides point out the error. yep, and by "enforcing" I was implying "adding this into submitting a patch guidelines on the wiki" >> • Components : I proposed to clean them a while ago. Now I have concrete >> & detailled propositions. > > I really don't see any problem with having lots of components. In fact > I'd vote for more rather than fewer. really ? I always need many seconds when I file a bug to say "is component XXX the right one" ? Other's opinion ? At least, please check my detailled proposition, some could really be merged/removed. >> • The "hardware" field is useless. > It isn't if you have a bug which is tied to your particular hardware. > If it's useless it's probably because people don't remember to set it. > Can we force it to default to "Any" since most bugs are not > hardware-dependent? >> • The 'OS' field is useless. > > Same as hardware: seldom-used, but maybe not useless. Can they be > hidden when "advanced fields" are hidden? By "useless" I was meaning "unused". I couldn't find a bug where the "hardware" info was relevant. Same for OS field. That's why I suggest to drop those fields. But having them being hidden would be OK for me. As you rise this point : can we put what we want on "No advanced fields" ? If yes, I would add Status/sponsored/priority/patch status to "no advanced fields" and remove OS and hardware from there, you're right. >> Could we hide all versions that are unsupported and have no bug opened >> now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions) > > Can Bugzilla be configured to show only a selection of versions for > which there are bugs? I'm in favor of this change if so. I don't know, and that was my proposition & hope... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Everyone, First off, Paul, thanks for getting this rolling. I've been thinking a lot about optimizing our Bugzilla set up to match today's current practices. ByWater Solutions uses Bugzilla internally for partners support needs, so I'm pretty well-versed in some of the configuration changes that we can make. Here's my take on Paul's comments: *Versions: * I think the versions in this list should correspond to the main branches on the Koha Git repo. So, we'd have 3.2.x, 3.4.x, 3.6.x and master. A bug report should be connected to the most current version (if it's a problem in 3.6.x and master, report is as master). For enhancements, I say we report them against master. Then, when the feature freeze rolls around, we take everything that has submitted code so far, and move it 3.8.x. If it makes it, great, if it doesn't, after release it gets moved back to master. We can delete old version values in BZ, but there isn't a way to obsolete them like there are with other field statuses. I think if we find anything on a version older than 3.0.x, we should probably: a) verify it's still relevant b) remove or re-report it in the current context *Component*: I'm with Owen that more is better than less, here. Each component controls the default Assignee, and having a more finely-grained default assignee's list will keep folks from getting overloaded with bug assignments (in theory). The universal problem here being, of course, that while folks can be ASSIGNED a bug, we can never guarantee they'll DO anything about it. We're all free agents, and cannot enforce any sort of assignment or timetable outside on a community-wide scale. Perhaps the issue with "which component to I choose" could be mollified with some kind instructions saying "It doesn't really matter, it'll get to the right place! Just be clear in your report" *Status*: We don't use the regular status field much at all, except to mark the patch as "resolved". Why don't we put the Patch Status into the regular ol' Status field? That would have a couple advantages: - Easier searching, since it's a default value, not a custom value - We can enable Workflows between statuses - We no longer have the dependency on Priority to control the display of this critical value I'll write up more about the potential for the Workflows, and how I hope the QA team can fit into that, in another post. *Priority:* I agree with Owen that this is pretty arbitrary... it may not be useful to us right now. *Severity:* we should keep, since it highlights issues in red and bold if they're critical or blocker *Hardware/OS*: should keep, as well, though they are very seldom useful. A little cluttersome, but a handy categorization for those few times when it's relevant. *QA Contact:* I'd like to move the 'bugs@lists.koha-community.org' from being the Default QA contact to a Global Watcher. This makes more sense to me, since it's always supposed to report on things, and if someone changed the QA contact on a bug report, the list would no longer get notified on update. The QA Contact field can then be used assign the QA portion of the patch submission process to one of the three QA team members (myself, Marcel de Rooy and Jonathan Druart). This'll make it easier for us to divide the work, and make sure that work submitted by one company is cross-checked by another. I think we should also start talking about making BZ a more central component in our Patch Submission Procedures. I know I don't use the patches list-serv now as anymore than a notification means. Everything I write, test and pass QA is done on Bugzilla (either through Git BZ or manually). I think that's the way with most of our other developers, as well More soon.... -Ian On Mon, Oct 24, 2011 at 11:52 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Hello koha-devel,
I'm doing a checking of our bugzilla usage. I've added some pages on the wiki about submitting a patch, and have some questions/propositions. Please give me your opinion about them. The propositions that won't be agreed by all (unanimity) will be discussed in a later IRC meeting.
Here they are, in random order.
• what's the difference between master and Rel_3_8 versions ? I feel "master" should not be used for bugs, only for ENH, and, when a patch is submitted for an ENH, it should be attached to "next planned version" (ie : Rel_3_8 those days)
• The priority is used to set "patch sent". This is a problem as we completly loose Priority field usage. A solution would be to have a patch status "patch sent" added, have the patch status always visible, and keep priority for what it's supposed to be, the priority. Patch status could then be "--" (patch not sent), "needs signoff", "does not apply"... as we have today.
• QA contact : could we do a better use of this field ? I know Ian & QA team are working/thinking to this question, so it's here just for reminder.
• Signed-off & passed QA = The signature and the QA process could be in any order: if a patch does not meet our QA rules, there's no need to test it if the QA team sees it. So maybe we have a field for "QA status" (-- / passed QA / failed) and the patch status for sign-off (-- / signed off / does not apply)
• For instance, I don't know how we could keep track of the "patch submitter" ? do we want/need ? I throw an open question here.
• bug status : it's NEW/ASSIGNED/RESOLVED and it's not really correctly used. Many bugs stay "new" = as of today, 12 bugs have a patch for version Rel_3_8 and are still marked "new". They should be "assigned". I propose to enforce the use of the "ASSIGNED". This question is connected to the question of the use of the default assignee i've asked a few weeks ago.
• Components : I proposed to clean them a while ago. Now I have concrete & detailled propositions.
http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap I've checked all entries with less than 30 bugs open, and propose something for each of them. The global idea is to have component entries close from modules we have in Koha. ∘ About, importedbugs, = no bugs, drop those entries. ∘ Authentication = 19 bugs, move them to "architecture, Internals and plumbing" ∘ Browser compatibility = 10 bugs, move them to "Architecture internals and plumbing" or "templates" ∘ bugs.koha-community.org = 2 bugs, move them to "websites, mailing lists,..." ∘ contribs.koha-community.org = 1 bug, move it to "websites, mailing lists,..." ∘ Developer documentation = 5 bugs, move them to "Architecture, internals and plumbing" ∘ Documentation = 11 bugs, keep them here, interesting for Nicole & doc writers ∘ Holidays = 2 bugs, move them to "Tools" ∘ Installation and upgrade = merge "command line" and "web-based" (20 and 24 repectively) ∘ Label printing = 27 bugs, move them to "Tools" ∘ MARC authority and MARC bibliographic (26 and 27 repectively) = we could merge them, not sure, i'm not proposing that, your opinion/thoughts about that ? ∘ MARC bibliographic staging/import = 14 bugs, move them to tools ∘ Self-checkout = 4, move them to "circulation" ∘ SIP2 = 18, move them to "circulation" or "Architecture, plumbing" ∘ Test suite = only 3, but keep them as we want to improve test coverage, it's to encourage ppl ! ∘ Transaction logs = 5, move them to "Tools" ∘ translate.koha-community.org = 2, move them to "Websites, Mailing lists,..." ∘ Z39.50, SRU, OpenSearch = 14, move them to searching
• The "hardware" field is useless.
http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=rep_platform&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap 12 are reported "MacIntosh", and not related to Mac specifically, others are PC/All/Other. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?)
• The 'OS' field is useless.
http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=op_sys&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap ∘ 5 bugs are "windows", and 3 are "others", it does not seem they are relevant. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?)
• Version field : there are many, only a few are used :
http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap Could we hide all versions that are unsupported and have no bug opened now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Le 24/10/2011 18:46, Ian Walls a écrit : > *Versions: * I think the versions in this list should correspond to the > main branches on the Koha Git repo. So, we'd have 3.2.x, 3.4.x, 3.6.x > and master. A bug report should be connected to the most current > version (if it's a problem in 3.6.x and master, report is as master). It's already the case (see the link i've provided in my initial mail) Report of bugs NEW or ASSIGNED : Rel_3_8 68 master 1031 rel_3_0 97 rel_3_2 132 rel_3_4 327 rel_3_6 129 unspecified 150 Total 1934 => we can discard all "old" versions. > For enhancements, I say we report them against master. Then, when the > feature freeze rolls around, we take everything that has submitted code > so far, and move it 3.8.x. If it makes it, great, if it doesn't, after > release it gets moved back to master. that makes sense. does anyone disagree ? * if you report a bug => report it with the version you're encountering the problem * if you report an enhancement => report it against master, the RM will move to rel_x_x when the patch is pushed. > We can delete old version values in BZ, but there isn't a way to > obsolete them like there are with other field statuses. I think if we > find anything on a version older than 3.0.x, we should probably: > a) verify it's still relevant > b) remove or re-report it in the current context There were only 2, i took care of them. > *Component*: I'm with Owen that more is better than less, here. Each > component controls the default Assignee, and having a more > finely-grained default assignee's list will keep folks from getting > overloaded with bug assignments (in theory). OK, i'm convinced. But we still could discard a few (about & importedbugs that have no entries, and bugs.koha-community.org & translate/koha-community.org. > The universal problem here being, of course, that while folks can be > ASSIGNED a bug, we can never guarantee they'll DO anything about it. > We're all free agents, and cannot enforce any sort of assignment or > timetable outside on a community-wide scale. My proposition is : * keep "NEW" by default * when someone want to endorse a bug (ie: and say "i'll do something"), set ASSIGNED. So by looking at "NEW" bugs, we will know what is orphan and waiting for a volunteer, and looking at old ASSIGNED, we could send a reminder to assignees to ask for confirmation they plan to do something (and if they say "no", we switch back to "NEW") > *Status*: We don't use the regular status field much at all, except to > mark the patch as "resolved". Why don't we put the Patch Status into > the regular ol' Status field? That would have a couple advantages: > > * Easier searching, since it's a default value, not a custom value > * We can enable Workflows between statuses > * We no longer have the dependency on Priority to control the display > of this critical value > > I'll write up more about the potential for the Workflows, and how I hope > the QA team can fit into that, in another post. I'm not sure I understand. > *Priority:* I agree with Owen that this is pretty arbitrary... it may > not be useful to us right now. OK. But the "patch sent" has nothing to do in "priority". The good solution would be to have "patch status" always displayed, with value "--" to say no patch. It's so true that, if you remove the "patch sent" and keep the failed QA (for example), the patch will still appear in the "failed QA" report ! > *Severity:* we should keep, since it highlights issues in red and bold > if they're critical or blocker Agreed. > *Hardware/OS*: should keep, as well, though they are very seldom > useful. A little cluttersome, but a handy categorization for those few > times when it's relevant. If you look at my initial mail and the link with report, you'll see it's never useful ! The more I think of it, the more I feel we need a "browser" field (IE / Firefox / Chrome / Opera / ... / Other), don't care of Hardware. OS maybe relevant for some very specific cases where the server is something strange (like HP-UX or Unix). But we don't have any bug where this information is usefull, so it's only theoric. > *QA Contact:* I'd like to move the 'bugs@lists.koha-community.org > <mailto:bugs@lists.koha-community.org>' from being the Default QA > contact to a Global Watcher. This makes more sense to me, since it's > always supposed to report on things, and if someone changed the QA > contact on a bug report, the list would no longer get notified on update. +1 > I think we should also start talking about making BZ a more central > component in our Patch Submission Procedures. I know I don't use the > patches list-serv now as anymore than a notification means. Everything > I write, test and pass QA is done on Bugzilla (either through Git BZ or > manually). I think that's the way with most of our other developers, as > well +1 (and i've updated the wiki that way a few hours ago) thread to be continued... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 24/10/2011 18:46, Ian Walls a écrit :
Everyone,
*Versions: * I think the versions in this list should correspond to the main branches on the Koha Git repo. So, we'd have 3.2.x, 3.4.x, 3.6.x and master. A bug report should be connected to the most current version (if it's a problem in 3.6.x and master, report is as master).
I've checked for old versions = as there are bugs attached to most of them (sometimes just 1), we can't drop the version. So, I propose = * create rel_1_2 and rel_2_0 versions * move all 1.2.x and 2.0.x bugs to those "generic versions" * move all 2.2.x bugs to rel_2_2 (rel_2_2 already exist) * move all dev_week bugs to rel_3_0 (dev_week had been created during the 1st ever hackfest, in Marseille, Kohacon06, it was before 3.0, the work to add zebra to koha) * drop all 1.2, 2.0, 2.x, and dev_week versions 2nd suggestion : have the old versions named xrel_1_2 (same for 2_0, 2_2, 3_0) to have them at the end of all lists -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (3)
-
Ian Walls -
Owen Leonard -
Paul Poulain