> This could probably be argued either way... Yeah, I guess it could :) > My view has been all along that we should prefer to use existing > extensions written and maintained by others. Perhaps we (the kind of > royal "we" of which I'm personally really not part of) could take on > maintainership of some extensions in the interest of improving kernel > documentation, but I think the goal should be that the extensions are > maintained outside of the kernel tree, that the extensions are > generally usable, and have a chance of attracting attention and > contributions from outside of the kernel community. (Note that this > doesn't preclude us from shipping the extensions in the kernel tree, > as long as it's updated from the upstream, not forked.) Right. I tend to agree, though in the particular case I'm looking at we'd probably have to fork outside the kernel, forming a new upstream, and then ship that version (or perhaps rewrite it, forming a new upstream, and then ship that - doesn't matter all that much) > (This is one part of me being unhappy about making it easy to run > arbitrary scripts to produce documentation; those will never be > generic, and we'll never be able to offload their maintenance outside > of the kernel. We should not think that we have some really special > needs in the kernel.) I agree that we don't necessarily have any special needs (*), but in cases like this (**) it does seem more practical to just ship the plugin with the kernel. Whether or not a separate "upstream" is formed for it could be a secondary question, although it does seem better to do so. (*) although not wanting to ship binary files *is* kinda special :) (**) where the upstream is essentially dead (for all I can tell) and severely limited to the point where a rewrite will be a better choice. Anyway, I'll have to see if we (Intel Linux WiFi team) actually want to do things this way. Using the existing blockdiag/seqdiag is practical since it all exists already. OTOH, a simpler and better-looking solution would also be nice, so if we do go this way I'll investigate more what we can do around this. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
