support to sort out matched clues to multiple files per package (e.g. one file per task)

[Alexander Sack]

Here two ideas out of my head to bootstrap discussion:

1. allow more than one info file per package: clues matched by package.info[.taskname] would be directed to package.taskname.html

2. add 'task-id' hint to clues, e.g. <clue task-id="duplicates"> and produce task-id specific output package.<task-id>.html

[Daniel Holbach (dholbach)]

3. We also discussed having <package>/<task>.html

Also, it'd be nice to not break .0.1 which expects ./<package>.info

[Alexander Sack (asac)]

ad 1.
  + break clue detection by old bughelper code
  + performance: the "naive implementation" will probably walk bugs for a package more than once.

ad 2.
  + bughelper code needs to know about output files (e.g. good-bye plain stdout)

[Alexander Sack (asac)]

we could prevent to break 0.1 by moving "per-task" info files to a sub-directory and including all of them through XML-entitiy mechanism in the main package.info file, which will live at top-level.

So structure would look like:

  bughelper-data/
  bughelper-data/package.info - include all package/task*.info through XML entity
  bughelper-data/package/
  bughelper-data/package/taskA.info
  bughelper-data/package/taskB.info

[Daniel Holbach (dholbach)]

I'm happy with that solution, Alexander. Did somebody try if this works out?

[Alexander Sack (asac)]

On Wed, Apr 25, 2007 at 06:38:51AM -0000, Daniel Holbach wrote:
> I'm happy with that solution, Alexander. Did somebody try if this works
> out?
>

I will try to split up firefox.info this way.

 - Alexander

[Markus Korn (thekorn)]

As we are currently having some huge , badly arranged output files (like firefox and totem) I want to push this bugreport again.
Alexander, did you try to split firefox.info into task related parts? - one possible solutions for this would be to use "XInclude" (example: [1]). The problem is that this technique has to be supported by bughelper and for this we have to edit the parsing of the info-files, with the result that feisty's bughelper.0.1 won't be compatible without codechanges

In my opinion the best solution would be to add an extra attribute "task" to the <clue>-element. We can implement explicit parsing of that attribute in the current version and work on a "output-per-task"-solution. bughelper.0.1 would just ignore that attribute and produce one output per .info-file.
As part of this changes we should think about a <description>-element to describe each task.

Any ideas, suggestions?

Markus

[1] http://www.zvon.org/xxl/XIncludeTutorial/Output/example12.html

[Alexander Sack (asac)]

i think I have tried to use entity includes, but iirc the parser we use chokes on it and doesn't load the complete document (e.g. just omittes the entities instead of loading them) ... nor does the parser complain about anything.

I will try to resume this in my brain and look what i still have here on hd.

Stay tuned,

 - Alexander