Re: [OpenDaylight Discuss] release planning for Helium

Luis Gomez

Very good point, and one advantage of having early documentation is that this can be tested at the same time of the system test development. I remember that for Hydrogen we were correcting few things on VTN documentation because all documentation was already there when we were writing the tests for VTN.


On Apr 2, 2014, at 8:34 AM, Thomas Nadeau <tnadeau@...> wrote:

One thing I would like to add to the release schedule is user and technical documentation. We also should add documentation milestones for each project/component itself. One possible way of doing the latter is to ask each project to go add a bugzilla entry for documentation.


On Apr 1, 2014, at 6:44 PM, Chris Wright <chrisw@...> wrote:

* Ed Warnicke (eaw) (eaw@...) wrote:
I’d also like to think about how the timeline interacts with new projects which would like to
join. We have a pipeline of project proposals that we need to hold creation reviews for… not *quite* sure
yet what the right thing is, but I think we should think about it.
I too am in the 'not *quite* sure' category.

Caught between welcoming more projects and facilitating timely release
of our existing projects.
I think there is a healthy balance between leaving some room for new projects to
come in and putting just enough time pressure on them to get moving. My concern
was that if we are *too* aggressive around start dates without adequate notice
then it becomes very hard for folks to actually pull themselves together and get moving
in time.

Of course, on the flip side… some time pressure really *does* get folks moving (as we saw
to our benefit in Hydrogen). The trick is to hit the sweet spot :)


Also, could you clarify what you mean by CI? (it could mean several things). I’m a little concerned about requiring
CI (for certain definitions thereof) at a point when Release Plans aren’t even finalized. I think more than anything its
going to be a matter of deciding some reasonable thing we mean by CI. It may also be useful to consider phasing it
in over a couple of milestones rather than as a single hard wall.
Yeah, I was thinking of pretty basic integration testing for what's there
at the milestone (maybe that's simply integration build + hello world
testing), and incremental improvements for what comes in future features
in the later milestones. So that we start off with a focus on quality,
and evolve as release plans finalize.

TSC mailing list
Discuss mailing list

Join to automatically receive all group messages.