Message ID | cover.1564603513.git.mchehab+samsung@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | ReST conversion patches not applied yet | expand |
On Wed, 31 Jul 2019 17:08:47 -0300 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > As promised, this is the rebased version of the patches that were not applied > from the /26 patch series because you had merge conflicts. > > They're all based on your docs-next branch, so should apply fine. > > The first one fixes all but one error with a broken reference. > > The only broken reference right now is due to a DT patch with was not > accepted (no idea why), but whose driver is upstream. All but 5/6 applied, thanks. jon
On Wed, Jul 31, 2019 at 02:17:34PM -0600, Jonathan Corbet wrote: > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > > As promised, this is the rebased version of the patches that were not applied > > from the /26 patch series because you had merge conflicts. > > > > They're all based on your docs-next branch, so should apply fine. > > > > The first one fixes all but one error with a broken reference. > > > > The only broken reference right now is due to a DT patch with was not > > accepted (no idea why), but whose driver is upstream. > All but 5/6 applied, thanks. Oh, I still hadn't reviewed this version of the SPI stuff :( There were outstanding questions about where it was going to get moved to but if I read the diff correctly it looks like it didn't actually get moved in the end?
Em Wed, 31 Jul 2019 21:20:07 +0100 Mark Brown <broonie@kernel.org> escreveu: > On Wed, Jul 31, 2019 at 02:17:34PM -0600, Jonathan Corbet wrote: > > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > > > > As promised, this is the rebased version of the patches that were not applied > > > from the /26 patch series because you had merge conflicts. > > > > > > They're all based on your docs-next branch, so should apply fine. > > > > > > The first one fixes all but one error with a broken reference. > > > > > > The only broken reference right now is due to a DT patch with was not > > > accepted (no idea why), but whose driver is upstream. > > > All but 5/6 applied, thanks. > > Oh, I still hadn't reviewed this version of the SPI stuff :( It is basically the one sent on that /26 patch series, just rebased on the top of docs-next. > There were outstanding questions about where it was going to get moved > to but if I read the diff correctly it looks like it didn't actually get > moved in the end? Yeah, it doesn't have the move. My understanding from our discussions is that we didn't reach a conclusion. In any case, I can send a separate patch with the move part once we reach an agreement about what's the best way to proceed (or you can do it directly, if you prefer so). Thanks, Mauro
On Wed, Jul 31, 2019 at 05:26:13PM -0300, Mauro Carvalho Chehab wrote: > Mark Brown <broonie@kernel.org> escreveu: > > There were outstanding questions about where it was going to get moved > > to but if I read the diff correctly it looks like it didn't actually get > > moved in the end? > Yeah, it doesn't have the move. My understanding from our discussions > is that we didn't reach a conclusion. Yes, that was my understanding too which was why I was surprised to see this going in. This is OK then, I'd have acked it. > In any case, I can send a separate patch with the move part once > we reach an agreement about what's the best way to proceed (or you > can do it directly, if you prefer so). I'm not likely to do anything without someone sending patches, I'm not clear on the utility of the move with the current division of the manuals. I don't know if it makes sense to have an embedded developer's manual as well?
Em Wed, 31 Jul 2019 21:37:12 +0100 Mark Brown <broonie@kernel.org> escreveu: > On Wed, Jul 31, 2019 at 05:26:13PM -0300, Mauro Carvalho Chehab wrote: > > Mark Brown <broonie@kernel.org> escreveu: > > > > There were outstanding questions about where it was going to get moved > > > to but if I read the diff correctly it looks like it didn't actually get > > > moved in the end? > > > Yeah, it doesn't have the move. My understanding from our discussions > > is that we didn't reach a conclusion. > > Yes, that was my understanding too which was why I was surprised to see > this going in. This is OK then, I'd have acked it. > > > In any case, I can send a separate patch with the move part once > > we reach an agreement about what's the best way to proceed (or you > > can do it directly, if you prefer so). > > I'm not likely to do anything without someone sending patches, I'm not > clear on the utility of the move with the current division of the > manuals. Same here: I do see value on having docs focused on their audience. Yet, I'm not so sure how worth is to break some subsystem documentation into books, as, on some cases, this would mean huge efforts. I'd prefer to see the big picture first, finishing the conversion and then looking at the resulting docs. Meanwhile, if someone needs something that it is at the wrong book, he can just use some search tool to seek what he needs, no matter on what book the relevant information is stored. > I don't know if it makes sense to have an embedded developer's > manual as well? Yeah, that's a good question. Jon is planning todo a documentation track at LPC. One of the things that should be discussed, IMO, is how we'll organize the books. I suspect that, once we finish the conversion of the remaining ~300 files to ReST, the next logical step is to check what are the gaps and have a list of pending tasks. Thanks, Mauro
On Wed, Jul 31, 2019 at 06:27:29PM -0300, Mauro Carvalho Chehab wrote: > Meanwhile, if someone needs something that it is at the wrong book, he > can just use some search tool to seek what he needs, no matter on > what book the relevant information is stored. OTOH it might be weird for the intended audience of the book. > Mark Brown <broonie@kernel.org> escreveu: > > I don't know if it makes sense to have an embedded developer's > > manual as well? > Yeah, that's a good question. > Jon is planning todo a documentation track at LPC. One of the things > that should be discussed, IMO, is how we'll organize the books. I'll be at Plumbers, not sure what the schedule's looking like yet though.