Hi Jonathan, Am 29.06.2016 um 18:24 schrieb Jonathan Corbet <corbet@xxxxxxx>: > Hi, Markus, > > I was glad to hear from you, but I have to agree with Jani: this is not > how things are done. Consider this one line: > >> 706 files changed, 123369 insertions(+), 752 deletions(-) > > Something like that will be a huge red flag to any kernel maintainer! > > In the kernel community, we have spent the last 25 years figuring out a > development model that is based on gradual, incremental changes, each of > which can be reviewed on its own merits. It does *not* encompass > wholesale replacements of existing code — even in situations where that > code was not just merged after a year of discussions, negotiations, and > false starts. Yes, my mistake, as I wrote to Jani. > I simply cannot accept this pull request. > > Markus, we all very much want your help in this work. You have expertise > and energy that could really push the documentation effort forward. But > it needs to be done the way kernel developers do it: cooperatively, > incrementally, and always mindful of the entire community's needs. > > I would love it if you would take the flat-table and man-page work, > separate them out, and make them work with the *existing* Sphinx-based > scheme. If you can do it soon, we can maybe get it into 4.8. Can you > focus on that for now, please? Yes, I will send you flat-table request in the next days. > As for the rest, what we have now is certainly far from perfect; we're > figuring a lot of this out as we go. Incremental improvements are > welcome, and each will be evaluated independently. Please help us to > make the kernel's documentation better that way. I'am willing to do so, but I need some help / suggestions: 1. I have this extensions in the scripts/site-python/linuxdoc. What do you recommend, how could I split this up in a patch series which is more evaluated. .. I wrote to Jani, that my approach was chaotic in the past and I'am sorry for this. But now I'am sitting in front of this bulk of source and I'am bit helpless how to split ... I will try to make it more elaborate, but it will be helpfull if you point me the right direction ... 2. What is the best way to ship these migrations or better I asked, what is your recommendation for a migration strategy. Jani says, that this better belongs to authors, but I have a doubt that we end with the migration in the next years, if we wait about every author. I think, supporting both infrastructures - the xml and the reST - over a long period is not the best option. What is your recommendation on this? Regards -- Markus -- > > Thanks, > > jon -- 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
