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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Sep 2007 14:29:40 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Natalie Protasevich <protasnb@...il.com>,
	David Rees <drees76@...il.com>,
	Daniel Walker <dwalker@...sta.com>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Björn Steinbrink <B.Steinbrink@....de>,
	eranian@....hp.com, ak@...e.de, linux-kernel@...r.kernel.org,
	Al Boldi <a1426z@...ab.com>
Subject: Re: Who wants to maintain KR list for stable releases?

On Thu, Aug 30, 2007 at 05:24:37PM +0200, Stefan Richter wrote:
>...
> 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.

"Contributing a cleanup" is what the Kernel Janitor Project
already offers.

But "Contributing an actual feature" is much harder:

You need a feature:
- with a realistic chance of being included and
- hard enough that the person suggesting it doesn't simply implement it
  himself instead of requesting it and
- easy enough that a newbie can implement it.

And the code should then be in a reasonable shape for being merged.

IMHO that's nearly impossible.

Realistically, offering a TODO item for a feature would require the one 
proposing it to do an amount of mentoring work that is not smaller than 
the amount of work he had to spend if implementing it himself.

This might be worth it if you know for sure the person you are mentoring 
stays active after completion of the feature - but this assumption is 
too often not true.

> Stefan Richter

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/