Designers and Builders (was: Who wants to maintain KR list for stable releases?)

Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Al Boldi]

Adrian Bunk wrote
> 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.

There are designers, and there are builders.

Can you tell me who is more important?


Thanks!

--
Al

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Adrian Bunk]

On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> Adrian Bunk wrote
> > 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.
> 
> There are designers, and there are builders.
> 
> Can you tell me who is more important?

That's a distinction that doesn't exist in practice:

Designing kernel features requires good knowledge of the area of the 
kernel that should be changed.

IOW: If you don't have the skills to implement it yourself you don't 
have the skills to do any good design.

> Thanks!
> Al

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

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Al Boldi]

Adrian Bunk wrote:
> On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > Adrian Bunk wrote
> >
> > > 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.
> >
> > There are designers, and there are builders.
> >
> > Can you tell me who is more important?
>
> That's a distinction that doesn't exist in practice:
>
> Designing kernel features requires good knowledge of the area of the
> kernel that should be changed.
>
> IOW: If you don't have the skills to implement it yourself you don't
> have the skills to do any good design.

I might agree with you on this wrt hacking around the kernel, but when it 
comes to introducing new subsystems, then we have a two fold situation:

  1.  Designing the internals of the new subsystem
  2.  Interfacing it with the rest of the kernel

Part 1 is completely independent of the implementation, it's part 2 that 
needs intricate implementation knowledge.

We recently had an example of this:  kexec based hibernation

So, what's wrong with tapping into people's design suggestions, and allowing 
others to implement it?


Thanks!

--
Al

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Adrian Bunk]

On Thu, Aug 30, 2007 at 04:54:24PM +0300, Al Boldi wrote:
> Adrian Bunk wrote:
> > On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > > Adrian Bunk wrote
> > >
> > > > 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.
> > >
> > > There are designers, and there are builders.
> > >
> > > Can you tell me who is more important?
> >
> > That's a distinction that doesn't exist in practice:
> >
> > Designing kernel features requires good knowledge of the area of the
> > kernel that should be changed.
> >
> > IOW: If you don't have the skills to implement it yourself you don't
> > have the skills to do any good design.
> 
> I might agree with you on this wrt hacking around the kernel, but when it 
> comes to introducing new subsystems, then we have a two fold situation:
> 
>   1.  Designing the internals of the new subsystem
>   2.  Interfacing it with the rest of the kernel
> 
> Part 1 is completely independent of the implementation, it's part 2 that 
> needs intricate implementation knowledge.

That's a perfect approach that works NOT.

Your subsystem needs to interact with the VFS or the block layer or 
whatever else parts of the kernel.

If you had ever written kernel code you would have known that your 
statement wasn't true.

> We recently had an example of this:  kexec based hibernation
> 
> So, what's wrong with tapping into people's design suggestions, and allowing 
> others to implement it?

People soon realize that you are making a fool of yourself when your 
suggestions show that you don't have a clue what you are talking about.

There's nothing wrong if this is the desired effect...

> Thanks!
> Al

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

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Al Boldi]

Adrian Bunk wrote:
> On Thu, Aug 30, 2007 at 04:54:24PM +0300, Al Boldi wrote:
> > Adrian Bunk wrote:
> > > On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > > > Adrian Bunk wrote
> > > >
> > > > > 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.
> > > >
> > > > There are designers, and there are builders.
> > > >
> > > > Can you tell me who is more important?
> > >
> > > That's a distinction that doesn't exist in practice:
> > >
> > > Designing kernel features requires good knowledge of the area of the
> > > kernel that should be changed.
> > >
> > > IOW: If you don't have the skills to implement it yourself you don't
> > > have the skills to do any good design.
> >
> > I might agree with you on this wrt hacking around the kernel, but when
> > it comes to introducing new subsystems, then we have a two fold
> > situation:
> >
> >   1.  Designing the internals of the new subsystem
> >   2.  Interfacing it with the rest of the kernel
> >
> > Part 1 is completely independent of the implementation, it's part 2 that
> > needs intricate implementation knowledge.
>
> That's a perfect approach that works NOT.
>
> Your subsystem needs to interact with the VFS or the block layer or
> whatever else parts of the kernel.
>
> If you had ever written kernel code you would have known that your
> statement wasn't true.
>
> > We recently had an example of this:  kexec based hibernation
> >
> > So, what's wrong with tapping into people's design suggestions, and
> > allowing others to implement it?
>
> People soon realize that you are making a fool of yourself when your
> suggestions show that you don't have a clue what you are talking about.
>
> There's nothing wrong if this is the desired effect...

I really didn't expect this kind of a response, but I guess when somebody 
runs out of arguments, then that's probably one of the responses to expect.

Really sad.


Thanks anyway!

--
Al

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Thu, 30 Aug 2007 07:31:24 +0300, Al Boldi said:
> Adrian Bunk wrote
> > 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.
> 
> There are designers, and there are builders.
> 
> Can you tell me who is more important?

The problem is not builders, or designers - this list has plenty of both.

What Adrian is talking about are the people who go to designers and say
"Build me something blue, with a design that doesn't work with the VFS".

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Alan Cox]

> The problem is not builders, or designers - this list has plenty of both.
> 
> What Adrian is talking about are the people who go to designers and say
> "Build me something blue, with a design that doesn't work with the VFS".

And the real test of whether someone is a good engineer or a dodgy
consultant then follows. The engineer says "no" the consultant says
"it'll cost ya" ;)

Humour aside don;t knock the people who have the ideas - in amongst all
the people wanting something that is insane are aluable pieces of
information if you can ever work them out - What they actually *want*
to be able to do, and sometimes ideas that are ones people used to the
technology wouldn't have - most are silly but just occasionally you get
the "that would be silly, we'd have to umm, interesting maybe we could,
I'll get back to you" type ideas.

Alan

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Al Boldi]

Alan Cox wrote:
> > The problem is not builders, or designers - this list has plenty of
> > both.
> >
> > What Adrian is talking about are the people who go to designers and say
> > "Build me something blue, with a design that doesn't work with the VFS".
>
> And the real test of whether someone is a good engineer or a dodgy
> consultant then follows. The engineer says "no" the consultant says
> "it'll cost ya" ;)

And the realist may say: look there is a middle way that reduces complexity 
many-folds and still gets us what we want.

> Humour aside don;t knock the people who have the ideas - in amongst all
> the people wanting something that is insane are aluable pieces of
> information if you can ever work them out - What they actually *want*
> to be able to do, and sometimes ideas that are ones people used to the
> technology wouldn't have - most are silly but just occasionally you get
> the "that would be silly, we'd have to umm, interesting maybe we could,
> I'll get back to you" type ideas.

Exactly, and that's what makes these ideas so valuable.


Thanks!

--
Al