Martin Bligh wrote:
>> If we have to use a 2-level component list, then I'd prefer we
>> do the following:
>>
>> Category = 2.5-linus, 2.5-ac, 2.5-mm, etc.
>> Component = something like
>> MM-Page allocator
>> MM-Slab allocator
>> MM-NUMA
>> MM-MTTR
>> MM-Others
>> FileSys-devfs
>> FileSys-ext2
>> FileSys-ext3
>> and so on...
>
>No. That ends up with 10 billion items all in one drop down list,
>which is a pain in the butt to use.
Well, it's not 10 billion items, but closer to....60 :-) And
the current component list is pretty complete, right? We don't
want to add anything that is not included in the official trees.
By the way, have you looked at Red Hat Bugzilla? They have
several hundreds of components in a single scroll-down list
(they define a component as a package). Of course, the list is
alphabetical, so it's not too bad to use it.
So I think 60+ is definitely a manageable number.
>
>> The above approach does not require any coding changes in Bugzilla
>> and is therefore preferrable.
>
>The current fix doesn't require coding changes either, and was trivial
>to implement. A long term solution should be done properly, by the
>addition of a tree field.
The approach above does not need any long-term solution. We should
try to avoid adding too much code above the base Mozilla code base
since it would be tough to upgrade the kernel bugzilla to a later
version of Mozilla code and it would introduce bugs which we don't
want.
Khoa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:39 EST