Re: Who wants to maintain KR list for stable releases?

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Natalie Protasevich wrote:
[Adrian Bunk wrote:]
>> Bugzilla is for tracking bugs, not for discussing possible
>> kernel features.
> 
> True, but some of them are categorized as bugs from the reporter's
> prospective, when they say "man page says" or "according to POSIX it's
> wrong". I am going to push ones that are feature suggestions,
> re-design suggestions, and some way implementation related out to the
> site that Rick is going to help to maintain, which is more of
> suggested projects list.
>>
>> Tracking feature or implementation suggestions wouldn't make sense.
>> Consider e.g. that there are several people on linux-kernel who often
>> write what they think the kernel should do but who never write a single
>> line of code themselves. There's no value in tracking such stuff.

I agree.

But I find it sensible...

> Yes, but some suggestions seem to make sense. How about evaluating it?
> and if they are real making it a possible project for someone who
> would do appropriate research, etc. And we move them from bugzilla
> where they don't belong to a development arena.

...to track very concrete feature-related TODO items.  One Issues &
Resolutions Database which I occasionally work with indeed distinguishes
between "bug", "new feature", "improvement", "task", whatever that
means.  The type of issue is the first question one is asked when one
enters a new issue.

'My' Linux kernel subsystem has a long virtual TODO list, with bugs,
missing features, and other kinds of items in it.  Since there is almost
no personnel, the list has a tendency to contain long-lived items.  Once
or twice or so I already added entries of the missing-feature kind to
bugzilla.kernel.org.  Doing this is questionable at the moment though
--- it adds noise to the database of actual bugs, since there is no way
to visually distinguish and filter bugs vs. missing features etc.

Of course, non-bug TODO items could as well be tracked elsewhere,
independently of bug tracking.  'My' subsystem has a wiki which could be
a good place for this.  Or I could start to post a TODO list on the
subsystem mailinglist in e.g. bimonthly intervals.


Al Boldi wrote in "Designers and Builders (was: Who wants to maintain KR
list for stable releases?)":
| So, what's wrong with tapping into people's design suggestions, and
| allowing others to implement it?

Design suggestions should really come from people who also know a lot
about the how-to.  This is even true to some degree about feature
requests.  Besides, I've got a feeling that regardless of the field of
τεχνη one works in, someone can only be a truly good designer if she or
he has also been a builder.

But back to the discussion.  A tracker is not a good tool for
brainstorming sessions, except perhaps for capturing conclusions after
the brainstorm, as far as they are suitable as input for actual work.

Also, "*allowing* others to implement it" has a strange ring to me.
Where I am around, there are always far too few people who fix things
and build things.  But very, very occasionally there is someone new who
wonders if there is an interesting TODO item which is perhaps in the
reach of his abilities.  Contributing a cleanup or an actual feature is
typically much easier than fixing an open, tracked bug.  (The bugs which
end up in the bugtracker are usually the difficult ones.)  The
contributor learns something and, in a rare turn of events, may
eventually become able and willing to join the bugfixing.
-- 
Stefan Richter
-=====-=-=== =--- ====-
http://arcgraph.de/sr/
-
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/