Re: Hoping to wrap up leaf/SR discussion
When it comes to the release vehicle, we'd need something where we make it easy to combine artifacts released at different times into a download for users to easily get stuff from multiple "releases", that is from different offsets or from both the "core" and "apps" releases or the like.
Perhaps we can extend the concept of offsets to not just milestones - but to the release itself? To illustrate with an example what I am saying:In the draft proposal currently we have M5 start of April for offset 0 projects and start of May for offset 2 projects. May be we have the release of offset 0 projects middle of May (say around May 20) - and all the offset 1 & 2 projects a month afterwards (June 26 as in the current draft). The offset 1-2 projects release should coincide with the stable update 1 of the offset 0 projects.I have not entirely thought through though.On Wed, Oct 29, 2014 at 8:41 AM, Colin Dixon <colin@...> wrote:_______________________________________________Sorry for the delay. Comments inline.(I'd also love to hear feedback from others. Thanks to Luis for already giving some.)--ColinOn Thu, Oct 23, 2014 at 10:42 PM, Lenrow, Dave <david.lenrow@...> wrote:Colin,
I feel like we’re getting very close. Thanks for hanging in there to make sure we’re aligned.
1) Bad is bad. OK.
2) Immature leaves should burden the platform (My spin) : respectfully disagree
3) Exclude leaves from SR: New proposal: Discourage leaves? That could work.
I think the problem here is one of emphasis or expectations. I see no benefit to anyone from including leaf projects in the SR, yet I feel that we have created an atmosphere where being part of the SR is somehow a badge of honor. If we make it clear that there is no benefit to anyone from being part of the SR if a package is not part of the base platform then the problem may solve itself.
So, I think the the critical advantage in being part of the core SR is that your bundle winds up in *the* download of the release. The instructions and infrastructure to make it easy to "install an app" on top of the core SR are currently missing. That is, each app—or maybe all apps in an App SR—would have to create their own release vehicle with their own download.
I'm not saying it's the wrong way to go if we get the tooling right, but right now, that's a pretty significant burden.
We shouldn’t have to exclude leaves, because it should be obvious to them that separation from the base platform is an asset, not a liability. In such an environment, I would expect the ( > 50%) leaf projects to never consider joining the SR and the problem would go away on its own.
If we work out the tooling and infrastructure needed to easily distribute and install "apps"/"leaves" after downloading the core SR, you might be right.
I think the added burden on the core platform projects is significant enough that it is worth asking a leaf project why they feel it is necessary to add overhead to the platform release.
Again, they should benefit from agility of independence from platform releases.
To Ryan’s point, I can work with folks to define this better if we need to describe process for releasing a leaf on a stable platform branch. I would suggest this is the best practice.
Looking forward to other thoughts from the community.
-drl
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc