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

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: starting with 2.7
    ... > interfaces are probably ready to go regardless. ... because you don't see any use to that particular feature that you can guarantee ... >> justify it anymore. ... It's possible that 2.6 has fewer of those known bugs, ...
    (Linux-Kernel)
  • Re: Kernel evolution: good and bad things.
    ... I was able to get a recent stable kernel. ... ide-scsi has been deprecated since roughly 2.6.0. ... application but with the ide-cd design (and bugs). ... You can think at because a feature have been deprecated, ...
    (comp.os.linux.misc)
  • Re: Why has the Metrowerks sign been taken down?
    ... > IB has so many bugs I doubt one or two more would make much difference. ... > - You're basing this on the assumption that this feature would take one ... > to read 'MENU' resources and convert them into menus in a nib. ... > haven't had their menus converted to nibs yet. ...
    (comp.sys.mac.programmer.codewarrior)
  • Re: [opensuse] curl error-connection time out
    ... I think this would be a great feature and would greatly help the ... downloading. ... When i changed the URL for my repositories back to ... Note that this is to be regarded as a prototype and there may be bugs - ...
    (SuSE)
  • Re: In VC++7.1 How do I...
    ... that is a wonderful feature. ... truly weird bugs that either fail to compile with VC7 or get runtime checks that VC6 ... Joseph M. Newcomer ... MVP Tips: http://www.flounder.com/mvp_tips.htm ...
    (microsoft.public.vc.mfc)