Re: [OpenDaylight Discuss] Lithium Cycle Hackfests

Ed Warnicke (eaw) <eaw@...>

So… my initial gut reaction about a hackfest around M3 and M5 is positive… but it might be helpful to think about the reasoning there…

To my mind, the reasons for hackfests might be something like this:

Between M1 and M2: Coordinate on cross project release planning and kicking off coding (Projects have initial release plans at M1, and coordinate cross project to finalize them by M2)

Around M3: Bringing functionality across the finish line (M3 is ‘functionality freeze’, meaning you should finalize the list of APIs you are exposing to others and the functionality you intend to ship, but 
you don’t have to ‘API freeze’ completely till M4).

Around M5: Bug fix, bug fix, bug fix (M5 is ‘code freeze’)

You might shorthand these as:

Hackfest:Plan (around M1)
Hackfest:Integration (around M3)
Hackfest:Bug Fix (around M5)

Do folks have other thoughts?


On 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 two.

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@...> wrote:
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@...> wrote:
> 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)
> Ed
> _______________________________________________
> Discuss mailing list
> Discuss@...

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

Join to automatically receive all group messages.