Re: Reiser4 Inclusion

[Tilman Schmidt <tilman@imap.cc>]

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

On 19.07.2006 21:04, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 19 Jul 2006 17:32:48 +0200, Tilman Schmidt said:
>  
>>Well, that doesn't make sense. You can't have your cake and eat it
>>too. Either you have out-of-tree code or you haven't. Documents
>>like stable_api_nonsense.txt explicitly discourage out-of-tree code,
>>which is formally equivalent to saying that all kernel code should
>>be in-tree. Therefore an attitude which says "go on developing that
>>code out-of-tree, it's not ready for inclusion yet" is in direct
>>contradiction with the foundations of the no-stable-API policy.
> 
> Which part of "read Documentation/SubmittingPatches.txt and do what it says,
> or it doesn't get into the kernel" do you have trouble understanding?

None. Why do you think I'd have? And what relevance does this have to
the present discussion?

> It isn't a case of "out of tree code or you haven't". There's actually
> *three* major categories:
> 
> 1) Code that's already in-tree and maintained.  These guys don't need to
> worry about the API, as it will usually get handled free of charge.
> 
> 2) Code that's out-of-tree, but a potential (after possible rework) candidate
> for submission (for instance, the hi-res timers, CKRM, some drivers, etc).
> These guys need to forward-port their code for API changes as they work
> towards getting their code into the tree.
> 
> 3) Code that's out-of-tree, but is so far out in left field that there's
> no way it will ever go in.  For instance, that guy with the MVS JCL emulator
> better not be holding his breath waiting.  And quite frankly, nobody else
> really cares whether they forward port their code or not.

Correct. And you could easily subdivide it further. Your point being?

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]