[release] [Boron planning] PTL discussion on Boron planning

Edward Warnicke hagbard at gmail.com
Fri Nov 6 14:37:34 UTC 2015

Reviving this discussion a bit...

There was some discussion around what MileStones would look like for a
2-month phased release like we've been discussing here.

Thinking through what our current Milestones do and mapping that may be of
some help:

M0->M1: Project Internal Release Planning, Decision to Join Release
M1->M2: Cross Project Release Planning
M3: Feature Freeze (aka: something working for the stuff you plan to
M4: API Freeze
M5: Code Freeze
RC: Test, Fix, Test, Fix, Test, Fix

Lets dig into some of the reasons for these (note: my personal take on the
reasons, other opinions welcome):

M0->M1: Project Internal Release Planning, Decision to Join Release
        For existing projects, after the release, we are typically more
than a little fried.
        Also, we have typically been running hard to make the release.
This basically precludes
        serious planning for the next release until the current release is
done.  Planning takes time.

        Hopefully, with smaller quicker releases, we will be less fried,
and with less time to plan for, less time
        will be required for planning.

M1->M2: Cross Project Release Planning
        With all projects 'in phase' for the SR, we need some time and
space for projects to collaborate about
        cross project needs.  With 'phase shifted' faster release cycles,
hopefully these can become 'continuous'

        Its one thing (with our current six month in phase) to need to
*really* get planning right because not getting what
        you need from another project could delay you almost a year.  But
if missing a cycle means only a 2 month
        delay, things get much more workable.  My 2c.

M3:  Feature Freeze
        I tend to see this as a 'focus the mind to make sure you really
have figured out you can deliver something'
        I see value in this, but frankly am having epic fail at this moment
expressing it clearly... Colin, could you
        help me out here a bit, I recall you articulate this much better
than I do.

M4: API Freeze
        We have API Freeze to provide some stability for consuming projects
around the APIs they are trying to consume
        from their upstream projects.  With 'phased' releases, Protocol
projects are always working with 'Release' (and thus
        intrinsically API Frozen) Kernel upstreams, and likewise for App
projects in relation to Protocols and Kernel.
M5: Code Freeze
        Gentlemen, put down your keyboards, and just bug fix from here.

Looking through all of this, I think that (putting aside for a moment
intra-offset dependencies) the motivation for API Freeze
lessens, and we might be able to move the 'Planning' to being a
'Continuous' exercise.

Looking at intra-grouping dependencies, I suspect that needs will vary
depending on the grouping of projects.

I am almost tempted to suggest something like this:

M0 -> Falls two weeks after last release (people need a chance to sleep ;)
RC1 -> Falls two weeks *before* release date, spins weekly.
RC2 -> Falls one week before the release date

and then the PTLs of each grouping (Kernel, Protocols, Apps) work out among
themselves if they need additional structure within the release.

So this would look like (note, dates chosen intentionally to be weird so as
to *just* illustrate spacing):

TSC Creates Simultaneous Release Plan
It requires Milestones:

M0 Kernel: 2015-01-01 - Release Opens
RC1 Kernel: 2015-02-15
RC2 Kernel: 2015-02-22
Release Kernel: 2015-03-01

M0 Protocol: 2015-03-01 - Release Opens
RC1 Protocol: 2015-04-15
RC2 Protocol: 2015-04-22
Release Protocol: 2015-05-01

M0 Apps: 2015-05-01 - Release Opens
RC1 Apps: 2015-06-15
RC2 Apps: 2015-06-22
Release Apps: 2015-07-01

Overall Release: 2015-07-01

And then the PTLs in each grouping (Kernel, Protocols, Apps) can add any
additional Milestones they need *within* their grouping
to assist with their intra-grouping needs (intra-grouping dependencies etc).

Basically, the TSC defines an 'Overall' Simultaneous Release Plan, and
delegates to the PTLs for the projects in each grouping
creating the Simultaneous Release Plan for each grouping (Kernel,
Protocols, Apps) layering any additional needs they have in terms
of Milestones etc on top, to fit the needs of that grouping.



On Mon, Oct 26, 2015 at 5:22 PM, Robert Varga <nite at hq.sk> wrote:

> Hello,
> In my mind NETCONF and RESTCONF are just different encodings of the same
> protocol, the implementation caveat is that we only provide NETCONF SB, but
> at some point we should be providing RESTCONF SB. In this regard I tend to
> view the 'pass-through' use case as being part of the kernel for
> architectural reasons.
> Services seem like a little misnomer, just because of the very general
> connotations of language suggests. From architectural perspective TSDR and
> TF serve two very different needs (both critical, but different
> relationship to 'core'). I have not followed TSDR closely, but TF fits into
> an 'adaptation framework', which would be something close to a convenience
> library.
> Bye,
> Robert
> On 2015-10-26 19:10, Edward Warnicke wrote:
> I think I agree with you that meta is important, but probably doesn't
> interfere with this sort of a scheme.
> I would say that RESTCONF and NETCONF are basically morally equivalent as
> MD-SAL bindings.  I'd tend to put MD-SAL bindings into core, but there is
> clearly room for other
> opinions there as well.
> So I think the really interesting question where things like
> topoprocessing, tsdr fit.  Are they protocols, or apps, or something in
> between (as you've shown here).
> Which ever way, I think its valuable to think about it.
> Ed
> On Sun, Oct 25, 2015 at 12:44 PM, Colin Dixon <colin at colindixon.com>
> wrote:
>> Having let this roll around in my head for a bit now, there's another
>> thing to consider. I think we really have ~5 classes of projects:
>> * kernel, e.g., odlparent, controller, mdsal
>> * protocols, e.g., openflow{plugin,java}, lisp, packetcable
>> * services, e.g., topoprocessing, tsdr
>> * apps, e.g., sfc, reservation, groupbasedpolicy
>> * meta, e.g., releng/*, docs, integration/*
>> I don't think the meta-projects interfere with this plan as they mostly
>> sit alongside this release process, but they might in the case of things
>> like integration.
>> Services might throw a bit of a wrench in things as they might depend on
>> protocols and be used by applications. I'm not sure though. Also,
>> obviously, many projects fall into multiple categories, e.g., NETCONF which
>> is both a protocol and a kernel element (for RESTCONF).
>> --Colin
>> On Thursday, October 22, 2015, Edward Warnicke < <hagbard at gmail.com>
>> hagbard at gmail.com> wrote:
>>> Comments inline...
>>> On Thu, Oct 22, 2015 at 6:02 AM, Colin Dixon <colin at colindixon.com>
>>> wrote:
>>>> I think this is exactly the kind of thing I was hoping we could at
>>>> least talk about during the Boron planning process. It's combining 3 ideas
>>>> we've tossed out at other times in other contexts:
>>>> 1.) overlapping SRs
>>> Hmm... I can see how you might think of it that way... I don't tend to
>>> think of it as overlapping, because within a grouping (Kernel for example)
>>> its just a series of non-overlapping releases.  But I can see how if you
>>> think across all three groupings it could be described as overlapping.
>>> I think both ways of looking at it are useful and valuable.
>>> Thinking more, I guess that your statement, in its precision is correct:
>>> overlapping SRs, but might be clearer if coupled with
>>> "project releases are *not* overlapping".
>>>> 2.) having the offsets actually consume the last released artifacts (or
>>>> at least snapshots from a stable branch)
>>>> 3.) shorter release cycles
>>>> I think the biggest risk is the two we've called out:
>>>> 1.) how do we compress a 6 milestone, 6 month release in 2 months? I
>>>> think it can be done, but requires care
>>> I am not entirely certain one way or the other if it can be done (though
>>> I'm hugely interested in trying).  I totally agree it requires
>>> some care.  I suspect that if it can be done it will come down to being
>>> able to shift what we do because of the changes in what we are doing.
>>>> 2.) what's the risk of having many more simultaneous stable branches
>>>> both in terms of
>>>>       a.) projects correctly merging patches to them and
>>>>       b.) what we can expect in terms of split focus from upstream
>>>> projects that are now more so than before having to split time between
>>>> fixing bugs on stability releases and feature development for the next
>>>> release.
>>> Yeah... the multiple active stable branches also worries me... not
>>> necessarily a show stopper, but definitely something to think hard about.
>>>> --Colin
>>>> On Sat, Oct 17, 2015 at 2:04 PM, Edward Warnicke <hagbard at gmail.com>
>>>> wrote:
>>>>> So... I had a random (possibly insane) idea, and wanted to put it out
>>>>> there for conversation.
>>>>> I haven't thought it all through, but figured its better for us to
>>>>> think through together than for me to think it through by myself ;)
>>>>> Various folks have talked about projects in ODL in three categories:
>>>>> 1)  Kernel - stuff everybody uses - e.g. odlparent, yangtools, mdsal,
>>>>> netconf , controller, aaa
>>>>> 2)  Protocols - stuff that talks to other systems, e.g.
>>>>>  openflowplugin, bgpcep, ovsdb-southbound, snmp, etc
>>>>> 3)  Apps - everything else
>>>>> What if we did the SRs phase shifted along those lines.  So Kernel
>>>>> starts a cycle, releases,
>>>>> and that becomes the input for the SB cycle, which finishes and
>>>>> becomes the input for the
>>>>> App cycle.  Obviously, these would have to turn faster.  So one
>>>>> example (dates made up for clarity, not reality, and thus intentionally
>>>>> chosen to be absurd)  might be:
>>>>> Kernel - Releases Boron: 2016-01-01
>>>>> Protocols Boron: 2016-03-01 (builds on Kernel Boron)
>>>>> App Boron: 2016-05-01 (builds on Kernel, Protocols Boron)
>>>>> Formal SR scoops up Boron of Kernel, Protocols, and Apps
>>>>> Kernel Carbon Release: 2016-03-01
>>>>> Protocols Carbon Release: 2016-05-01 (builds on Kernel Carbon)
>>>>> App Carbon Release: 2016-07-01 (builds on Kernel, Protocols Carbon)
>>>>> Formal SR scoops up Carbon of Kernel, Protocols, and Apps
>>>>> From the point of view of a particular project, this becomes a 2 month
>>>>> release cycle.  *But* its a 2 month release cycle where *mostly*
>>>>> the stuff a project depends on only changes at the very beginning
>>>>> (when they pick up the release from the cycle before).
>>>>> Pros (that I can see, others may see more or less):
>>>>> 1)  Faster Release Cycles good from point of view of delivering new
>>>>> stuff more often (every 2 months)
>>>>> 2)  Projects *mostly* are working on stable releases after their
>>>>> initial integration at cycle start
>>>>> Cons (that I can see, others may see more or less):
>>>>> 1) Faster Release Cycles bad from the point of view of having enough
>>>>> time and space to plan, collaborate, and execute
>>>>> 2) Continuous Disintegration: Protocols are only picking up Kernel
>>>>> once its already Released and moved on to its next cycle, etc
>>>>> 3) Intrinsically implies more 'stable' branches being maintained at
>>>>> once.
>>>>> Differences that might be Neutral, but are quite different:
>>>>> 1)  Faster Release cycles basically force overlap of executing one
>>>>> cycle while planning for the next
>>>>> And then there's the issue of how we would transition to this, because
>>>>> it would:
>>>>> a)  Have some startup issues.  It might be as simple as having Kernel
>>>>> start a 2 month release cycle, Protocols and Apps
>>>>> integrates against its SNAPSHOTS (just that first time) and
>>>>> transitions to its release artifacts when it releases.  It might
>>>>> be more complicated
>>>>> b)  We would have to rethink a lot what we ask for when for SRs.  I
>>>>> suspect a lot of the reasoning for that
>>>>> stuff would shift because of this sort of change, and additionally, I
>>>>> suspect a lot of it becomes *way* to heavy for
>>>>> 2 month cycles (and as mentioned, planning would probably shift a fair
>>>>> bit too).
>>>>> I curious to hear other peoples thoughts/ideas.
>>>>> Ed
>>>>> On Thu, Oct 15, 2015 at 1:41 PM, Edward Warnicke <hagbard at gmail.com>
>>>>> wrote:
>>>>>> That is a good idea :)
>>>>>> I think there are threads of that in some of the continuous release
>>>>>> conversation, but its good to call it out explicitly :)
>>>>>> Ed
>>>>>> On Thu, Oct 15, 2015 at 1:01 PM, Luis Gomez <ecelgp at gmail.com> wrote:
>>>>>>> I am not sure this is already here but something we would like to
>>>>>>> have next release is a process for upstream projects to introduce “major”
>>>>>>> changes.
>>>>>>> BR/Luis
>>>>>>> On Oct 15, 2015, at 9:24 AM, Keith Burns <alagalah at gmail.com> wrote:
>>>>>>> Ok seems like this thread kind of died on the vine :)
>>>>>>> I'll throw some things I'd like to see us focus on:
>>>>>>> 1. Tooling.
>>>>>>> Specifically how we solve some of the issues that come with
>>>>>>> "multi-repo/monolithic release" I wish I could take credit for that phrase,
>>>>>>> but I'm stealing it.
>>>>>>> - how we consume or not consume upstream changes as downstream
>>>>>>> projects (semantic versioning etc)
>>>>>>> - how we can do rollbacks (similar to above)
>>>>>>> - project management tools and standards, be it JIRA etc. There's a
>>>>>>> lot of flexibility, I think we should perhaps formalise things a little
>>>>>>> more so things like Release Reviews can be more indepth, which to me is a
>>>>>>> pre-requisite to any discussion of Mature/Core projects.
>>>>>>> 2. Continuous Integration vs Simultaneous Release
>>>>>>> - How can projects continuously integrate yet still have the end
>>>>>>> consumer have something tangible. ie one idea might be projects snapshot a
>>>>>>> version when they are ready, with dependency versions its compatible with,
>>>>>>> integration does packaging etc <- this idea might be horrible but expresses
>>>>>>> one way of doing it, rather than just arm waving about CI/CD.
>>>>>>> 3. End user consumability.
>>>>>>> - we need to keep going further with "what problem is it that we
>>>>>>> solve (as ODL vs/with/compared-to alternatives)" and demonstrable
>>>>>>> user-stories/use-cases that show OOB what it is we can do. I know folks are
>>>>>>> on this already, just saying, if we were to focus on something, this would
>>>>>>> be something :)
>>>>>>> 4. More work on "best practises"/"feedback".
>>>>>>> - I'm dancing around "architectural guidelines" but lets face it,
>>>>>>> Offset2 projects consume Offset0/1 projects, Offset1 projects consume
>>>>>>> Offset0. As such, we are their customer, but also their partner, so it
>>>>>>> behoves us to have some commonality on how things are consumed (ie take
>>>>>>> transaction chains as an idea... how/when should they be used? Does
>>>>>>> everyone know? If you aren't using them and should, do you have plan?) and
>>>>>>> vice versa, what do we need Offset0/1 projects to do that would make life
>>>>>>> better? ie "when I get a notification from the datastore that this IID was
>>>>>>> changed, I want to know the contents of this other IID at the same time to
>>>>>>> save me a read".... or "I want to get more granularity on notifications
>>>>>>> other than BASE, NODE, SUBTREE ie full XPATH" etc)
>>>>>>> On Fri, Oct 2, 2015 at 3:55 PM, An Ho <An.Ho at huawei.com> wrote:
>>>>>>>> +1 on documentation.  While talking to the PTL of new projects,
>>>>>>>> I've received the feedback that we need more constructive up-to-date
>>>>>>>> tutorials and documentation.  This will help new projects and new
>>>>>>>> developers.
>>>>>>>> Best Regards,
>>>>>>>> An Ho
>>>>>>>> -----Original Message-----
>>>>>>>> From: release-bounces at lists.opendaylight.org [mailto:
>>>>>>>> release-bounces at lists.opendaylight.org] On Behalf Of Jamo Luhrsen
>>>>>>>> Sent: Friday, October 02, 2015 3:46 PM
>>>>>>>> To: Mathieu Lemay; Robert Varga
>>>>>>>> Cc: Release (release at lists.opendaylight.org)
>>>>>>>> Subject: Re: [release] [Boron planning] PTL discussion on Boron
>>>>>>>> planning
>>>>>>>> I'd like to see documentation bubble up the priority list at some
>>>>>>>> point.
>>>>>>>> JamO
>>>>>>>> On 10/02/2015 03:23 PM, Mathieu Lemay wrote:
>>>>>>>> > I agree with Robert, I think CR and cleanup definitely would
>>>>>>>> help. The
>>>>>>>> > first step in CR would be to remove any versions from pom.xml
>>>>>>>> files..
>>>>>>>> > and centralize versioning so that the pipeline can inject the
>>>>>>>> version
>>>>>>>> > in the next stage based on the first build step. I think though
>>>>>>>> that some of that cleanup could be done now and before Boron. I would like
>>>>>>>> to see the proper inheritance and versions removal done in Be so that in Bo
>>>>>>>> we can get started on the CR work properly. I am in sync with wanting to do
>>>>>>>> a release that will improve performance and scale vs adding features.
>>>>>>>> >
>>>>>>>> > Cheers
>>>>>>>> > Mathieu
>>>>>>>> >
>>>>>>>> > On Fri, Oct 2, 2015 at 5:58 PM, Robert Varga <nite at hq.sk <mailto:
>>>>>>>> nite at hq.sk>> wrote:
>>>>>>>> >
>>>>>>>> >     At the start of the Boron release, I think we need to first
>>>>>>>> focus on getting CR up and running before anything else.
>>>>>>>> >
>>>>>>>> >     During that time it would make sense for people who do not
>>>>>>>> actively working on getting that up and running to work do some
>>>>>>>> house-cleaning. We
>>>>>>>> >     definitely have things we can clean up: pom.xmls,
>>>>>>>> feature.xmls (everybody needs to be on features-parent!), Sonar warnings,
>>>>>>>> JavaDoc warnings,
>>>>>>>> >     checkstyle warnings. In my experience it not only improves
>>>>>>>> overall code quality, but it also tends to bring out work items for
>>>>>>>> refactoring and
>>>>>>>> >     overall improvements.
>>>>>>>> >
>>>>>>>> >     As for the theme, looking back at history, Hydrogen was
>>>>>>>> feature-packed, Helium was mostly stability and scale, Lithium was
>>>>>>>> features, Beryllium is
>>>>>>>> >     a mix of features and stability. I think we could use a
>>>>>>>> scale/debt release with a focus to make the entire eco-system tighter and
>>>>>>>> more coherent.
>>>>>>>> >
>>>>>>>> >     Bye,
>>>>>>>> >     Robert
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >     On 2015-10-01 20:09, alagalah wrote:
>>>>>>>> >>     PTLs, (and anyone else who wants to chime in)
>>>>>>>> >>
>>>>>>>> >>     What would YOU like to see be the focii, timing etc anything
>>>>>>>> for the Boron release?
>>>>>>>> >>
>>>>>>>> >>     Some ideas but definitely not an agenda:
>>>>>>>> >>
>>>>>>>> >>     - timing?
>>>>>>>> >>     - release plan feedback? Too many steps, too few, more data
>>>>>>>> required in plans?
>>>>>>>> >>     - should there be an ODL theme? (unicorns? stability?
>>>>>>>> performance? scale? technical debt? interproject work? ODL use case?)
>>>>>>>> >>     - tools: weather report, dependency mapping, ability to
>>>>>>>> identify upstream issues and local rollback, JIRA
>>>>>>>> >>     - offset mechanism. Is it working? Is it being fair? ie are
>>>>>>>> offset x projects really offset x or should they be x-1 ?
>>>>>>>> >>     - Whats an API ? (API Freeze... because I make a YANG file
>>>>>>>> to not have a local Java Map so I can work with clustering, is that an API
>>>>>>>> ??)
>>>>>>>> >>     - Clustering? HA? Federation? (see use cases).
>>>>>>>> >>
>>>>>>>> >>     Feel free to say what ISN'T working. Maybe we may not know
>>>>>>>> what a great solution is, but perhaps others feel your pain.
>>>>>>>> >>
>>>>>>>> >>     It would be helpful in your response if you identified if
>>>>>>>> you are
>>>>>>>> >> a PTL and for what project (as I don't know everyone ... sorry
>>>>>>>> :( )
>>>>>>>> >>
>>>>>>>> >>     Cheers
>>>>>>>> >>     Keith
>>>>>>>> >>     PTL GBP
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>     _______________________________________________
>>>>>>>> >>     release mailing list
>>>>>>>> >>     release at lists.opendaylight.org <mailto:
>>>>>>>> release at lists.opendaylight.org>
>>>>>>>> >>      <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >     _______________________________________________
>>>>>>>> >     release mailing list
>>>>>>>> >     release at lists.opendaylight.org <mailto:
>>>>>>>> release at lists.opendaylight.org>
>>>>>>>> >      <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > *
>>>>>>>> > **
>>>>>>>> > Mathieu Lemay*
>>>>>>>> > //President & CEO//
>>>>>>>> > Inocybe Technologies
>>>>>>>> > 1-888-445-7505
>>>>>>>> > <http://www.inocybe.com/>www.inocybe.com <
>>>>>>>> <http://www.inocybe.com/>http://www.inocybe.com>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > release mailing list
>>>>>>>> > release at lists.opendaylight.org
>>>>>>>> > <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> release mailing list
>>>>>>>> release at lists.opendaylight.org
>>>>>>>> <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>>>>> _______________________________________________
>>>>>>>> release mailing list
>>>>>>>> release at lists.opendaylight.org
>>>>>>>> <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>>>> _______________________________________________
>>>>>>> release mailing list
>>>>>>> release at lists.opendaylight.org
>>>>>>> <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>>>> _______________________________________________
>>>>>>> release mailing list
>>>>>>> release at lists.opendaylight.org
>>>>>>> <https://lists.opendaylight.org/mailman/listinfo/release>
>>>>>>> https://lists.opendaylight.org/mailman/listinfo/release
>>>>> _______________________________________________
>>>>> release mailing list
>>>>> release at lists.opendaylight.org
>>>>> https://lists.opendaylight.org/mailman/listinfo/release
> _______________________________________________
> release mailing listrelease at lists.opendaylight.orghttps://lists.opendaylight.org/mailman/listinfo/release
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/release/attachments/20151106/e1dd3838/attachment-0001.html>

More information about the release mailing list