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

Bug #109547 reported by Alexander Sack
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bug Helper
Confirmed
Wishlist
Unassigned

Bug Description

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

Tags: server
Revision history for this message
Daniel Holbach (dholbach) wrote :

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

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

Changed in bughelper:
importance: Undecided → Wishlist
status: Unconfirmed → Confirmed
description: updated
Revision history for this message
Alexander Sack (asac) wrote :

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)

Revision history for this message
Alexander Sack (asac) wrote :

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

Revision history for this message
Daniel Holbach (dholbach) wrote :

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

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 109547] Re: support to sort out matched clues to multiple files per package (e.g. one file per task)

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

Revision history for this message
Markus Korn (thekorn) wrote :

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

Revision history for this message
Alexander Sack (asac) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.