| 1 |
Enrico Weigelt wrote: |
| 2 |
> * Jakub Moc <jakub@g.o> schrieb: |
| 3 |
> |
| 4 |
> <snip> |
| 5 |
> |
| 6 |
> |
| 7 |
>>> That somehow looks like the guided file-a-new-bug form we had some time |
| 8 |
>>> ago. |
| 9 |
>>> |
| 10 |
>> It's still there, just not linked from homepage (and needs a few touches |
| 11 |
>> here and there) |
| 12 |
>> |
| 13 |
>> http://bugs.gentoo.org/enter_bug.cgi?format=guided |
| 14 |
>> http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&format=guided |
| 15 |
>> |
| 16 |
> |
| 17 |
> hmm, looks like an good start, but for me doesn't go far enough. |
| 18 |
> The user still has to type in too much manually. |
| 19 |
> |
| 20 |
> I'd suggest an tool, where the user *first* gives the package name, |
| 21 |
> and the tool gathers any necessary information (version, useflags, |
| 22 |
> make config, ...). Dependend on the package, this tool may ask specific |
| 23 |
> questions or gather specific information (ie. on web applications, |
| 24 |
> we'd be interested in webserver, browser, certain network configs, ...). |
| 25 |
> |
| 26 |
> The usage should be as simple as possible for normal users, so they |
| 27 |
> have great interest in using it. For example, asking the user to |
| 28 |
> look for similar bug is probably good for devs/maintainers, but |
| 29 |
> uncomfortable for plain users. But we shouldn't forget, that all |
| 30 |
> the plain users are (in their mass) also an important contributor. |
| 31 |
> (they find and report bugs, which probably never would be found |
| 32 |
> by the maintainers). |
| 33 |
> |
| 34 |
> |
| 35 |
> cu |
| 36 |
> |
| 37 |
I think this is an excellent idea. I wrote an automated trouble |
| 38 |
ticketing system years ago for the mainframe and it's an excellent way |
| 39 |
to get quality information into the system. The one drawback was that |
| 40 |
we ended up having a lot more bugs entered into the system. Once you |
| 41 |
have the shell it wouldn't be hard to hook it into batch processes and |
| 42 |
have emerge automatically send bug reports when it fails. When this |
| 43 |
happens you end up with multiple, identical bug reports because users |
| 44 |
tend to re-create the error a few times before they head to the forums |
| 45 |
or bugzilla for help. On the plus side it would be much easier to find |
| 46 |
duplicate bugs since the titles would be uniform. |
| 47 |
|
| 48 |
Glide |
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives