lcer - lunar compile error report (simplifying support)

[Jean-Michel Bruenn]

Hello,

first of all, i like that some devs like the idea. I have still some
questions about what to implement, what data to collect, etc. So if
someone wanna drop in on irc, pm me and discuss a bit with me about
whats useful and whats not .. I'd be glad :)

Now let me answer some things:

> Duncan
> 2. Why does it have to be part of lunar/theedge? Can't it be a module
>    on its own? The user asks on #lunar, someone says 'lin lcer' and
>    then run 'lver module' and we'll have a look.

It doesn't have to, but it would bring some advantages, for example we
could track problems "automatically" (at least if a user whishes to
enable this feature, not all users will enable it because of security
issues, they don't like their name and the versions of the kernel
displayed on websites) however - if 20 users enable this feature, and
we see after 2 days (right after we updated application xyz) that 10 of
those 20 users had the same issue compiling it, we know we have done
something wrong.. (Yes, this shouldn't happen.)

> Duncan
> 3. Bearing in mind that the current Bug Tracker needs a good clean out,
>    who maintains the lcer reports page?

We have two options here. A "solutions" part is integrated, this means
a developer (option 1) could answer a problem report with a "solution",
or even a user (option 2) if we open the solution/message part to
everyone. I don't know which is better. The good thing about lcer is,
that it merges equal problems, so there's no need to make posts like
"this is a copy of bug report xyz" which is the case in most available
bug trackers. I might be able to link username and passwords of
developers with some help of striker with the lunar page to simplify
login. A few things can be done automatically by the system, for
example if someone uses unsupported optimizations, the system could
print out "Sorry, you're using not-safe-optimizations, we aren't
supporting this."

> Stefan
> On the contrary, I often find it necessary to ask for the compile log,
> or at least the last 100 rows or so. I like the idea anyway.

This leads to the question: Should i fetch the whole compile log, or
only the last 100/200 lines?

> Stefan
> The system could be self cleaning, logs older than X months get nuked.
> Least effort from devs is the way to go, if it can be automated it
> should :)

Yes, we could let's say close problems after 1 or 2 months, and display
them as closed/solved and after another 2-3 months we could nuke them
(delete). For that i need some good values from you :) (how many months
for what or no delete at all, just "close")

Another Question is: Should a user be able to post additional
information? Or will this just end in confusion? (the less to read, the
easier to help)