Re: [OpenDaylight Discuss] Lithium Cycle Hackfests

Kyle Mestery <mestery@...>

On Wed, Nov 19, 2014 at 2:21 PM, Thomas Bachman
<bachman@...> wrote:
In theory, adding the Functionality, API, and Code freezes with ~1
month between them, along with the added testing requirements keeps us
from being faced with integrating a large number of commits within a
very short period of time. That said (and maybe I'm being cynical
here), it seems as though there will be a point in the development
where a bunch of code gets merged that forces us work through
integration issues. Do folks think this will be M3? M5? I guess I
ask this only because that's likely when we'd want people to be in
close proximity so they can collaboratively work through these issues
as rapidly as possible. My gut tells me this is is more likely to be
M5 than M3, though the release plan seems to say it should be M3. I'd
personally make a best guess as to which one it is and go with meeting
up then.
Given how distributed the project is (maybe it's not and everyone
working on this except me, you and a few others are not in the bay
area), this is exactly why we don't want to require hackfest
attendance and promote 3+ hackfests each release. If we require people
to be face to face to solve these issues, the project won't scale, and
it's lifecycle will be limited by the scaling factor of a handful of
people. We need to be able to work in a distributed fashion to grow
the project. Doing these things distributed and virtual allows that
growth. We've reached the point in the project where this should be

It's that reason, along with the cost of travel (both money and time)
which are my big beefs with all these hackfests. They may be
productive in the short term, but they set a bad precedent for the
project in the long-term, and really limit it's growth.

I know OpenDaylight uses OpenStack as a role model, and the recent
pushback towards mid-cycle meetings for OpenStack should serve as a
warning as to what happens when "face to face" becomes a requirement
for development of an open source project.

I'll go back to lurking now. :)


Also -- given that there's a 1 month span between offset 0 and offset
2 for these, when do we want to plan it? Should it be for the offset
2 date?



On Wed, Nov 19, 2014 at 12:19 PM, Ed Warnicke (eaw) <eaw@...> wrote:
I think that may be a good idea… any thoughts on what that mix would look like?

On Nov 19, 2014, at 10:53 AM, Thomas D. Nadeau <tnadeau@...> wrote:

Can we accommodate a mix of virtual and real participants to lessen the requirement for travel?


On Nov 19, 2014:9:14 AM, at 9:14 AM, Kyle Mestery <mestery@...> wrote:

-1 to 3 Hackfests for this release. That's asking people not in the
bay area to travel an inceasing amountl, as it doesn't even include
the ODL Summit, which is a fourth trip. At some point, the travel
becomes too much. Thus, the virtual hackathon's become a nice way
forward and allow everyone to participate who doesn't have a monstrous
travel budget.

On Tue, Nov 18, 2014 at 5:34 PM, Phil Robb <probb@...> wrote:
Just an update folks on the hackfests.

We are looking for venues in the bay area for January (the week of the 12th
being preferred). Thus far, the venues we've contacted have no
availability, but some venues have not yet responded. We should know more
by the end of the week.

I would prefer that we hack all at the same location, so let's only talk
about a distributed/virtual hackfest if we can't find a venue that would
hold us all. I'm estimating that 75 to 100 people would show up.

On the other Lithium Hackfest dates, is there consensus that having
hackfests around M3 and M5 (in addition to the January Hackfest) are
preferred? Throw a "+1" out if you like the idea and a "-1" if you think
it's too much.

Your thoughts are much appreciated.



On Mon, Nov 10, 2014 at 1:50 PM, Colin Dixon <colin@...> wrote:

I like the idea of getting people together.

My gut reaction is that cross-project release planning will be somewhat
harder than we might hope at a face-to-face event because attendance from
the different projects is likely to hit and miss. That doesn't necessarily
mean that it's a bad idea, but just that we'll need to try really hard to
get at least some people from each participating project to join the
hackfest virtually if they can't attend physically and make sure that we are
very inclusive of our virtual participants—even more so than in the past.

I think getting together for a real hackfest, i.e., one where we push on
code in between M2 and M3 is actually a really good idea. My guess is that
there are logical groups of people working on code that could benefit from
actually sitting at a table together and hacking through things for a day or

I think in general the idea that we would have hackfests for a few days
around M1, M3 and M5 each release with a larger event loosely following the
release is maybe a good general pattern.


On Mon, Nov 10, 2014 at 2:00 PM, Abhijit Kumbhare <abhijitkoss@...>

Should have clarified - I like Luis' idea as well.

On Mon, Nov 10, 2014 at 11:59 AM, Abhijit Kumbhare
<abhijitkoss@...> wrote:

I like this idea as well.

On Mon, Nov 10, 2014 at 11:16 AM, Luis Gomez <ecelgp@...> wrote:

I like the idea.

Besides this one I also see value in gathering around:

- M3: to define and hack the project features
- M5: to cut stable branches and do some bug fixing


On Nov 10, 2014, at 10:50 AM, Ed Warnicke (eaw) <eaw@...>

Would it make sense (or be possible) to have a Hackfest for Release
Planning to 1/13-15 in Santa Clara?

The idea would be to get folks together for inter project
collaboration on Release Plans (and hopefully to write
some code towards that).

Thoughts? (including other points in the Release Cycle where
Hackfests might or might not make sense)

Discuss mailing list
Discuss mailing list

Discuss mailing list

TSC mailing list

Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

Discuss mailing list
Discuss mailing list
Discuss mailing list
Discuss mailing list
Discuss mailing list

Join { to automatically receive all group messages.