On Thu, 2011-11-10 at 12:21 -0500, Jon McCann wrote:
> I'm not really sure what to make of this mail to be honest.
> I'm approaching this from a user experience design point of view
> and don't know anything about the code. The reason why I've
> called these conceptual components is that is how I'm thinking
> about the system.
> Whether it corresponds directly to code isn't my primary concern.
> Also, I've tried to be clear that this is a strawman
> in order to start a discussion.
> The main Problem Reporting wiki page seemed to be too much
> about goals for you so I tried to make something a bit more
> detailed. A place for us to start.
A place to start what? We do not plan to start anything.
We have an already existing code base. We plan to improve/change it.
Let me explain this with an example. Let's got back to the days of Linux
1.x. It was essentially a single-CPU, non-parallelized kernel.
Of course, this was not acceptable. A kernel which scales to
many-CPU machines was needed.
What would kernel developers say to a conceptual design of a new
kernel which is specifically targeted to be very scalable,
but if that design was not even mentioning existing kernel 1.x
They would say "well... it's nice, but you know, we already have
the code we intend to work on. We do not plan a grand redesign.
We want to improve scalability of EXISTING code".
Do you understand what I mean?
> The main point here is to make sure we're in agreement
> on the objectives and the terms.
That's what I'm asking you. What are your goals? I have a feeling you
think we know what you are doing, but the point is, we don't.
I spend some time trying to articulate my thoughts, questions, etc.
What I got in reply is a top-post answer "uh, your email is strange".
My email had three questions. You responded to none.
I am confused...
> I'm not sure why you feel the need to staunchly defend abrt
> when I haven't even mentioned it directly.
I think I do not defend abrt per se, it's more along the lines
of trying to understand why you did not mention abrt.
I thought that this discussion will follow this model:
"abrt does X, we want it to do Y instead, lets figure out
what needs to be changed".
> It may in fact already do many or most of the things on this page.
> Or very easily be adapted to do so. I have no idea.
> That is our task to figure out.
Good. How do you want to figure it out?
I thought that reading abrt deployment guide could be a good start
to understand abrt. Do you want to do that or not?
If not, what's your plan?
since ABRT should be easy to use for not-skilled users we should hide
less used options into an advanced view - since I expect more such
options in the future (we shouldn't prevent skilled users to access more
advanced options..) I created made this patch which adds support for
<advanced-options> tag in the event xml - such options is hidden in the
advanced expander in the configuration dialog. Run-tested, please review.
- the xml syntax is:
<option type="text" name="Bugzilla_Product">
<_label>OS Product name</_label>
I did some changes in code to make it compile with glib 2.31 which is in
F17, tested it against glib 2.30 (Fedora 16) and it works, but can cause
problems with older Fedoras (RHEL6 ??) - probably won't as the functions
were marked deprecated for a long time... Any feedback appreciated...
This patch makes the search box on the backtrace page to saerch thru all
editable items in problem_data highlights the strings in the associated
textview and also highlights the tab containing the textview. This
should fix rhbz#748457. Run tested.