I think we got of on the wrong foot here and there is a big
misunderstanding going on. In every project one of the most important
things is to set-up a common vocabulary so everyone understands what
others are talking about. We have it inside ABRT team so when Jon used
different words it might sound like he wants something totally different
which is not true. So before starting shooting questions and demanding
answers, lets make sure we all speak the same language.
To me it doesn't seem like Jon is proposing something too different than
what we wanted from the beginning:
ABRT was meant to be easy-to-use tool for 2 reasons:
1. usable by non-skilled users
2. to send the report/find the solution with as little user effort as
We made the things better in both of these cases, but let's be honest we
did it from the developer perspective and the user interaction suffers
from that (not just gui/cli but the whole interaction). Jon put together
his ideas where we could get and how it could work better, now it's up
to us to to provide counter offers for what we don't like, agree on the
final solution and start moving towards it. How we will get there is a
discussion which can only happen after we agree where we want to get and
that's what Jon is trying to do - set the main big goals.
On 11/10/2011 07:22 PM, Denys Vlasenko wrote:
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.
- to start cooperating with Jon and to start moving to common goals, not
starting from scratch...
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?
- well, again, no one asks us to to a big redesign, our current code can
cover a lot from Jon's ideas and I really don't see a place where he
suggests we should start over
> 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".
- so we're on agreement here, Jon just started with the Y, now we need
identify what we need to change to get there (or discuss the Y a bit
> 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?
- Denys, your previous email with explanations about reports
generators/problems/data collectors and how they map to our current
design was exactly what I think we should do now and what Jon expects us to.