Caolan McNamara wrote:
On Fri, 2007-05-18 at 16:23 +0200, Bernd Eilers wrote:
Caolan McNamara wrote:
Hi Caolan,
ReHi,
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 :-)
Nah those are usually in different libs or are even in a packaged
extension etc. and would thus not cause a same-match-different-problem
situation. Potential problems arise only if code is in same lib :-)
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.
Yes but there currently is no such thing as a "distro" and
"distro_version" variable defined in the reportmail.xml file format,
there is only the build string and the product variable meaning to
support this and to support such distros not using a release from
masterworkspace model for being able to map back to their corresponing
debug information we must extend the fileformat used for reportmail.xml
and update it´s corresponding DTD for being able to send this new
information. This can of course be done but must be coordinated, see
also my other reply about changing stuff like that.
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.
Yeah well I was first misunderstanding your intentions of course a
little bit and thought you were talking about a common system that could
be used by ANY distro ANY platform ANY product ANY developer, but this
doesn´t seem to be the case.
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.
Agreed.
And unfortunatly I must add that getting near prefection in that area is
not being possible at all :-(
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.
I would rather have us extend the reportmail.xml file format spec for
that. There is already support for namespaces in the definition about
how that file looks like which groups different types of information
send in that file into categories so adding "other userful data" maybe a
matter of creating corresponding namespace for each type of "useful
data" while adding stuff like distroid might fit into exiting namespaces
just adding new attributes as optional attribures to available elements
like those being used for officeinfo version information.
For stuff that does not fit into the XML format there is of course
always the possibility to have additional "binary" or "text" attachments.
With versions of known troublesome software you mean system libraries
being used which are known to maybe cause trouble?
Bootstraprc in the installation currently keeps other relevant
information send like product name etc. a distroid etc. might fit there
as well so we don´t need an additional config file just more entries in
the existing one for the installation.
C.
Kind regards,
Bernd Eilers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
