On Fri, Oct 19, 2018 at 05:30:50PM +0200, Miroslav Benes wrote: > On Fri, 19 Oct 2018, Josh Poimboeuf wrote: > > > On Fri, Oct 19, 2018 at 02:54:55PM +0200, Miroslav Benes wrote: > > > On Thu, 18 Oct 2018, Josh Poimboeuf wrote: > > > > > > > Hi all, > > > > > > Hi, > > > > > > thanks for the update. > > > > > > > The live patching microconference at LPC in Vancouver is scheduled for > > > > Nov 15, Thursday afternoon, from 2:00PM-4:45PM. > > > > > > > > With a 30 minute conference break in the middle, we only have 2 hours > > > > and 15 minutes of scheduled time. Similar to previous years, we have a > > > > lot of topics to cover in a short amount of time. > > > > > > > > For everyone planning to attend this year, please review the following > > > > (tentative) schedule: > > > > > > > > https://linuxplumbersconf.org/event/2/timetable/?view=lpc > > > > > > > > I did my best to fit everything in. I gave each topic a 15 minute slot, > > > > except for arch support, which got 30 minutes (10 minutes per arch). > > > > > > > > Our goal is to maximize discussions and minimize "presenting". Jiri has > > > > proposed a 0-1 slide rule: all presenters only prepare a single slide > > > > (or even no slides). > > > > > > > > I'm happy to shrink/add time to different topics as needed. Or if you > > > > don't think a topic is worth discussing, we can drop it to give more > > > > time elsewhere. > > > > > > > > And of course, during the session, if a topic ends early, we can move on > > > > to the next one ahead of schedule. > > > > > > > > Any thoughts/comments/suggestions? > > > > > > Yes, I have a slightly different proposal. > > > > Thanks a lot for the feedback. > > > > Funnily enough, I already tried to organize it how you suggest: with the > > pre-break session for topics which I anticipated would have more > > discussion. > > > > My thinking was that some of the "newer" topics would generate more > > discussion. Whereas arch support would be more of a status update which > > has already been discussed in detail on the mailing lists. But it's > > really a guessing game to a certain degree. > > It is. > > > > There are four important topics which need to be discussed in my opinion > > > (and it is important to stress out "my opinion"). > > > > > > - GCC optimizations. We can connect it with "live patch creation tooling" > > > probably. > > > > Yeah, it does make sense to bundle these together. > > > > > - Arch support - s390 consistency model, arm64 support, powerpc objtool > > > > What needs to be discussed for arch support, other than a summary of > > what has already been discussed on the lists? > > If there were s390, arm64 and powerpc maintainers, we could talk to them > about objtool and reliable stacktraces in person. If I am not mistaken, > Joe analyzed s390 and came to a conclusion that it should be ok. Powerpc > is reliable, objtool might be "nice to have". We don't know about arm64 > yet. > > And if there's time (ehm), we can even talk about objtool and how to make > it more arch-independent. > > > > - Livepatch callback state management > > > - Livepatch is too flexible > > > > Agreed that these two topics may generate some good discussion. > > > > > Then there are two topics which look more like presentations and it would > > > definitely be interesting to have them. > > > > > > - User space live patching (libpulp) > > > > I don't know anything about this topic other than its title, but I would > > expect there to potentially be a *lot* of discussion, considering the > > broad scope of user space live patching. > > Joao has a proof of concept as far as I know. I expect he could give us a > presentation. > > Joao, what's your intention? > > > > - eLivepatch > > > > This is also something "new" which could generate more discussion, IMO. > > But maybe not as much as the other topics. > > > > > I did not forget about Jason's slot. I just don't know where to include > > > it, because although there was email about it I still don't understand > > > what it is about. It could go to the first group as well as to the second. > > > > Jason can correct me, but I think the idea is, would it make sense to > > have upstream livepatch "streams" which mirror the stable trees. > > Another "new" idea, I can imagine a lot of discussion there. > > Ok. so... > > > > Now, I'd split the time to two slots. One about 1:45 hour long for > > > the first group of topics. The rest for the second group. > > > > The LPC people have recommended that we have a 30 minute break from > > 2:30-3:00, because that's when the snacks will be there. If we follow > > that guideline, the first slot is 1.5 hours, and the 2nd slot is 45 > > minutes. > > ...in the end we can have two discussion slots with a break in between. > > > That said, I'm ok with shortening or moving the break if we need to. > > > > > We can easily decide if a discussion is fruitful, or not and then move > > > to a next topic. I think it could be better than fixed time slots. > > > > I definitely agree that we should be flexible, and skip ahead (or fall > > behind) the schedule as needed. However, IMO, the fixed time slots > > would still be useful to help us know whether we're ahead or behind > > schedule at any given time. What do others think? > > Agreed. I've modified the schedule a bit based on the discussion so far: - Moved GCC optimizations next to patch creation tooling (do we still need 30 minutes total to cover both?) - Moved elivepatch to the second session. - Moved libpulp and livepatch stable trees down to the end of the first session. Of course this is all still very tentative and open to any further suggestions. -- Josh
