On 2013-02-25 20:24, Dave Steele wrote: > On Mon, Feb 25, 2013 at 8:45 AM, Andreas Beckmann <a...@debian.org> wrote: >> In general I think we should allow the flexibility to have a per-section >> known-problems-directory setting, so each report Section should generate >> its own problem list and not get a global one passed >> > OK, but out of scope of the patch set under consideration, which replaces > the existing detect_well_known_errors with one that sorts by rdep.
In branch report-problem_integration you have 4db22544 "piuparts-report - add known Problems class list to Section." That should be dropped, instead create_problem_list() should be called with a proper directory argument ... (That's only for the reporting side of the problem, and the patch that made me aware of the possibility to have different known_problem sets.) > As you are saying, if this was designed from scratch for integration with > piuparts-report, it would lean much more heavily on packagesdb. What is on > the table is not an integrated solution. It is a replacement for the bash > script, with issue rdep sorting. > I understand that you don't like the way that I solved the known_problem > .conf issues in the patches that come after this submission, and that you > believe they aren't the right way to add issues to piuparts-report. I am OK I'm primarily concerned about reimplementing a bad piece of code (the second half of dwke that creates the .tpl files) in order to build a new feature on top of it. The perfectionist in me would like to fix things properly first. I really do like the approach of reviewing patches before inclusion as more eyes may spot more problems - and may result in a different implementation (e.g. recently embedding get_config_value.inl -> sourcing read_config.sh). Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
