Open Stack

Le 14 août 2014 21:56, "Joe Gordon" <joe.gordon0 at gmail.com> a écrit :
>
>
>
>
> On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange <berrange at redhat.com>
wrote:
>>
>> On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
>> > On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith <dms at danplanet.com> wrote:
>> > >> I'm not questioning the value of f2f - I'm questioning the idea of
>> > >> doing f2f meetings sooo many times a year. OpenStack is very much
>> > >> the outlier here among open source projects - the vast majority of
>> > >> projects get along very well with much less f2f time and a far
>> > >> smaller % of their contributors attend those f2f meetings that do
>> > >> happen. So I really do question what is missing from OpenStack's
>> > >> community interaction that makes us believe that having 4 f2f
>> > >> meetings a year is critical to our success.
>> > >
>> > > How many is too many? So far, I have found the midcycles to be
extremely
>> > > productive -- productive in a way that we don't see at the summits,
and
>> > > I think other attendees agree. Obviously if budgets start limiting
them,
>> > > then we'll have to deal with it, but I don't want to stop meeting
>> > > preemptively.
>> >
>> > I agree they're very productive. Let's pick on the nova v3 API case as
>> > an example... We had failed as a community to reach a consensus using
>> > our existing discussion mechanisms (hundreds of emails, at least three
>> > specs, phone calls between the various parties, et cetera), yet at the
>> > summit and then a midcycle meetup we managed to nail down an agreement
>> > on a very contentious and complicated topic.
>>
>> We thought we had agreement on v3 API after Atlanta f2f summit and
>> after Hong Kong f2f too. So I wouldn't neccessarily say that we
>> needed another f2f meeting to resolve that, but rather than this is
>> a very complex topic that takes a long time to resolve no matter
>> how we discuss it and the discussions had just happened to reach
>> a natural conclusion this time around. But lets see if this agreement
>> actually sticks this time....
>>
>> > I can see the argument that travel cost is an issue, but I think its
>> > also not a very strong argument. We have companies spending millions
>> > of dollars on OpenStack -- surely spending a relatively small amount
>> > on travel to keep the development team as efficient as possible isn't
>> > a big deal? I wouldn't be at all surprised if the financial costs of
>> > the v3 API debate (staff time mainly) were much higher than the travel
>> > costs of those involved in the summit and midcycle discussions which
>> > sorted it out.
>>
>> I think the travel cost really is a big issue. Due to the number of
>> people who had to travel to the many mid-cycle meetups, a good number
>> of people I work with no longer have the ability to go to the Paris
>> design summit. This is going to make it harder for them to feel a
>> proper engaged part of our community. I can only see this situation
>> get worse over time if greater emphasis is placed on attending the
>> mid-cycle meetups.
>>
>> > Travelling to places to talk to people isn't a great solution, but it
>> > is the most effective one we've found so far. We should continue to
>> > experiment with other options, but until we find something that works
>> > as well as meetups, I think we need to keep having them.
>> >
>> > > IMHO, the reasons to cut back would be:
>> > >
>> > > - People leaving with a "well, that was useless..." feeling
>> > > - Not enough people able to travel to make it worthwhile
>> > >
>> > > So far, neither of those have been outcomes of the midcycles we've
had,
>> > > so I think we're doing okay.
>> > >
>> > > The design summits are structured differently, where we see a lot
more
>> > > diverse attendance because of the colocation with the user summit. It
>> > > doesn't lend itself well to long and in-depth discussions about
specific
>> > > things, but it's very useful for what it gives us in the way of
>> > > exposure. We could try to have less of that at the summit and more
>> > > midcycle-ish time, but I think it's unlikely to achieve the same
level
>> > > of usefulness in that environment.
>> > >
>> > > Specifically, the lack of colocation with too many other projects has
>> > > been a benefit. This time, Mark and Maru where there from Neutron.
Last
>> > > time, Mark from Neutron and the other Mark from Glance were there. If
>> > > they were having meetups in other rooms (like at summit) they
wouldn't
>> > > have been there exposed to discussions that didn't seem like they'd
have
>> > > a component for their participation, but did after all (re: nova and
>> > > glance and who should own flavors).
>> >
>> > I agree. The ability to focus on the issues that were blocking nova
>> > was very important. That's hard to do at a design summit when there is
>> > so much happening at the same time.
>>
>> Maybe we should change the way we structure the design summit to
>> improve that. If there are critical issues blocking nova, it feels
>> like it is better to be able to discuss and resolve as much as possible
>> at the start of the dev cycle rather than in the middle of the dev
>> cycle because I feel that means we are causing ourselves pain during
>> milestone 1/2.
>>
>> > >> As I explain in the rest of my email below I'm not advocating
>> > >> getting rid of mid-cycle events entirely. I'm suggesting that
>> > >> we can attain a reasonable % of the benefits of f2f meetings
>> > >> by doing more formal virtual meetups and so be more efficient
>> > >> and inclusive overall.
>> > >
>> > > I'd love to see more high-bandwidth mechanisms used to have
discussions
>> > > in between f2f meetings. In fact, one of the outcomes of this last
>> > > midcycle was that we should have one about APIv3 with the folks that
>> > > couldn't attend for other reasons. It came up specifically because we
>> > > made more progress in ninety minutes than we had in the previous
eight
>> > > months (yes, even with a design summit in the middle of that).
>> > >
>> > > Expecting cores to be at these sorts of things seems pretty
reasonable
>> > > to me, given the usefulness (and gravity) of the discussions we've
been
>> > > having so far. Companies with more cores will have to send more or
make
>> > > some hard decisions, but I don't want to cut back on the meetings
until
>> > > their value becomes unjustified.
>> >
>> > I think this gets to the crux of the original email -- we are
>> > increasingly needing cores to understand the overall direction nova is
>> > going. You could argue for example that our failure to land many high
>> > priority blueprints in Juno is because cores aren't acting in
>> > coordinated a manner. So, we're attempting to come up with ways to
>> > improve coordination.
>>
>> Having mid-cycle meetups where only a subset of cores will attend doesn't
>> feel like an great way to improve the coordination between /all/ cores.
>>
>
> This thread is starting to sound like its going in circles.
>
> Yes, requiring or even assuming all nova-cores and interested non-cores
will be able to attend the mid-cycles is not very realistic
> Yes, making final decisions at the mid-cycles without giving folks who
were not there a chance to chime in is not good
> Yes, anyone who attended a mid-cycle thinks they are incredibly valuable
>
> So going forward what about: continue having the mid-cycles meetups f2f,
but make it easier to attend the mid-cycle remotely.  At the Icehouse
midcycle we had several people attend via google hangout (AFAIK Sean Dague
and Andrew Laski) and were able to participate in the discussion (although
from what I hear it was not ideal for them, but better then nothing). That
way we get the issue of budget and travel burden doesn't become a blocker
to attending the mid-cycles.

I had the chance to remotely attend by phone this midcycle sessions related
to scheduler so I can just +1 what you said.

That said, a few notes from someone who was having some trouble following
the discussion :
- voice is not enough, video is better to correctly join the discussion
(just enforcing a common sense but that's really helpful and less dividing)
- at least someone present should proxy the voices if there are some
difficulties, ie. be identified and responsible for watching/answering an
IRC chan
- feedback thru etherpad with a summary of the discussion followed by a q&a
is worth it because of some possible misses while discussing

Also I liked the efforts to handle the sessions I followed at a decent time
for a remote people in France, so I'm just thinking that we should probably
make a call on each subject to see who's interested so we could arrange
meeting times wrt time difference with these people

-Sylvain
>
>>
>> Regards,
>> Daniel
>> --
>> |: http://berrange.com      -o-
http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-
http://virt-manager.org :|
>> |: http://autobuild.org       -o-
http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-
http://live.gnome.org/gtk-vnc :|
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140814/ce5289e5/attachment.html>