Caolan McNamara wrote: Hi Caolan,
[... snip ...] What I'm thinking about aiming at is a shared cross-distro crash repository where we can auto submit the distro OOo crashes, and the distros can plug in their various stack mappers, with quick and dirty gnomebugzilla-alike tooling to merge the duped backtraces together.
Some additional toughts about crash reporting that have just come to my mind:
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. For such builds of course anything send as version information in the reportmail.xml file is kind of unusable. When distributions can not agree on a common release mechanism which is based on releasing from MasterWorkspaces / ChildWorkspaces we might not be able to find common ground on how to handle crash reports and what data must be send by crash-reporting for storing it in a cross-distro crash repository.
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 because it is based on code of distribution-B which was not yet contributed back via ChildWorkspaces or in some private patch applied but where the reports stacktrace just looked similar to annother one which caused by a problem in common code.
There is some kind of numeric buildid used by OOo and there is also a build string in a config file containing that plus some other information, eg. name of a ChildWorkspace, used when building. Problem is that the build string does not contain information like wether we have an SRC680 or something like OOF680 etc. 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 requiring a mechanism ( web service etc.) to request a new uniq buildid offered somewhere.
C.
Kind regards, Bernd Eilers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
