On Fri, 2007-05-18 at 16:23 +0200, Bernd Eilers wrote: > Caolan McNamara wrote: > > Hi Caolan, > > As far as I have heard there are distributions which currently do not > release from MasterWorkspaces or ChildWorkspaces but do in fact use some > kind of more or less complex system to release something which is kind > of a mix of code from current MasterWorkspace together with some patches > from integrating stuff from some unfinished/not yet integrated > ChildWorkspaces together with maybe some patches which are not even yet > on some ChildWorkspace etc. or maybe even plus some code hold back from > contributing back for some time for creating some kind of artifical > feature advantage etc.
Like a StarOffice email merge component, or a StarOffice headless vcl plugin, or a StarOffice blog component. That kind of thing maybe :-) > For such builds of course anything send as > version information in the reportmail.xml file is kind of unusable. I'm not totally convinced, certainly the info is unusable unless you have the right source for that version which crashed, but again the distros have the matching source for each build, so if there's a distro-specific backported patch or an experimental addition in play the data will only be relevant for that distro. I don't see it as a huge problem really. Just have the disto crash reporter autofill in the distro and distro OOo package version when submitting the report, if the various stacks from different distros match exactly then it's in code which has the same state across distros, if it doesn't then it remains a problem for the afflicted distro only. > It may be a tedious and time consuming tasks for developers of > distribution-A having to sort out false positives in the crash > repository for things like regression or new bugs in code which is not > even in their distribution. Well I'd foresee that it would be up to each distro to look at their own stacktraces so I don't see that occurring, but I don't have a feel for the scale of how many reports might be in question. But indeed, distros that drift from a common base would have to re-do work done by others to note that their trace is the same as others. I naively see a quick auto comparison on the unmapped stack to see if they are exactly the same as something else and autodup it, and then on the remainder map back to source and do a fuzzy comparison to make a list of candidates and leave it up the humans to make a decision. Perfection wouldn't be a goal, the odd crash here and there sucks but it's the regular occurrences that I'm interested in. > Therefor the backend must have means to map the numeric buildid to such > information. > Thus the numeric buildid needs to become globally unique across distributions Yeah, there needs to be a unique identified for the version of OOo and the distro itself. I was (vaguely) thinking more of simply a config file for a crashreporting tool with a "distro"."id" and have the tool submit the "standard" report wrapped in some extra data like the distro.id and "other useful data", like versions of known troublesome software. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
