This thread is going many directions all at once, so I'll somewhat rudely top-reply and call out specific points rather than extend each sub-thread. Thierry, I suspect your strawman will address all of these points and more.
Decoupling: I'm very much in favor. For a long time, devs at summits have been making choices between customer meetings, conference talks, and design sessions; the three things conflated on each other make productive focus very challenging. On the monetary side, my OpenStack budget has grown too large, and my ability to send devs so they can get work done is conflated with marketing costs, etc. When the cost per dev rises, we reach a spot where each of us can send fewer of them. Not a good outcome. Conference frequency: If we want semi-annual conferences, we might consider an Operators Conference and a Users Conference. It would allow companies to decide where to invest dollars and time according to who they're aiming to serve. I'd expect fair overlap between the two, with power users at the OpsConf, and forward-thinking operators at the UsersConf. We might consider a 3-4 month lag from release for these to allow vendors to pick up the latest release and do interesting things on top of it; I suspect that would do a lot to drive a virtuous cycle of release-create-showcase-adopt that would be good for the community overall. Lack of dev participation in conferences: I think the conferences will still be the main vehicle for technical companies to showcase the technical work they're doing to technical customers who are interested in the very technical thing that is OpenStack. I don't believe you can succeed in that environment without sending smart developers to talk about it. There will be fewer, true, but I believe the interactions will be better and more focused. Dev summit organization: another voice for centralized organization, at least for all the non-technical venue/food/recording logistics. I co-organized a successful small tech conference for a number of years. It's very hard work. That said, might be interesting to try a self-organizing unconference framework inside that space. Dev summit cycles: If we're doing this, I think we should decide what the purpose of the dev summit is (to make sure we don't lose any of the purposes it's serving now as we separate it); back plan from the release dates we want; and put them on the calendar. I like the releases we have now (Apr/Oct). I'd be sad at one yearly megarelease. Midcycles: I think for many projects they'll be just as useful. For others, they'll turn out to be superfluous. My guess is that the core projects will still strongly need them in order to manage their higher complexity. And, as someone responsible for sponsorship of some of these, and the budget for sending folks to most or all of these, I'm still going to be in strong support of them. Thanks for opening this thread, Jay. It's been brewing for a while. --j > On Feb 8, 2016, at 2:56 AM, Thierry Carrez <thie...@openstack.org> wrote: > > Daniel P. Berrange wrote: >> [...] >> I really agree with everything you say, except for the bit about the >> community doing organization - I think its fine to let function event >> staff continue with the burden of planning, as long as their goals are >> directed by the community needs. > > Exactly. > >> I might suggest that we could be a bit more radical with the developer >> event and decouple the timing from the release cycle. The design summits >> are portrayed as events where we plan the next 6 months of work, but the >> release has already been open for a good 2-3 or more weeks before we meet >> in the design summit. This always makes the first month of each development >> cycle pretty inefficient as decisions are needlessly postponed until the >> summit. The bulk of specs approval then doesn't happen until after the >> summit, leaving even less time until feature freeze to get the work done. > > I agree that the developer event happens too late in the cycle (3 weeks after > final release, 5 weeks after RC1 where most people switch to next cycle, and > 8 weeks after FF, where we start thinking about the next cycle). That said, I > still think the dev event should be "coupled" with the cycles. It just needs > to happen earlier. > > -- > Thierry Carrez (ttx) > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
