Re: Managed Release Plan 2.0
I would propose that in Sodium, we only support one release: Managed Distribution/RPM/Debs.
Self-Managed projects would be responsible for generating their own distribution, as well as packaging their own RPM/Debs, and compiling their own release notes. Ideally using some scripts (as Robert suggested), but realistically referencing some documentation page would be sufficient. Essentially, Self-Managed projects would be treated like any other End-User of OpenDaylight, except they use OpenDaylight infrastructure (Git, Jenkins, Nexus, etc).
From: Daniel Farrell [mailto:dfarrell@...]
Sent: Thursday, October 18, 2018 10:12 AM
To: Robert Varga <nite@...>
Cc: An Ho <An.Ho@...>; 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Stephen Kitt <skitt@...>
Subject: Re: [integration-dev] Managed Release Plan 2.0
On Thu, Oct 18, 2018 at 5:54 PM Robert Varga <nite@...> wrote:
On 18/10/2018 15:53, Daniel Farrell wrote:
> Reviving a very old thread, thinking we should start discussing on
> today's integration call.
> Also, from an Int/Pack perspective, two thoughts:
> * It was a mess to have "two" Fluorine releases (Managed, Manged+Self).
> That really doesn't work with version numbers.
Agreed, but I think we will at some point arrive at two releases:
Platform and Managed Apps...
In the spirit of common contributions to Managed projects, I might could do this level of split. It would be a huge TODO though.
> * If we end up going with a single Managed-only distro as the official
> release, and ask Self-Managed projects to produce their own release
> artifacts, I don't think we'd be able to support packaging those as
> RPMs/Debs. I can imagine ways to do it technically, but I can't allocate
> cycles to drive that work. If a Self-Managed project wants RPMs/Debs
> they would need to contribute.
How difficult it to maintain that?
Just to maintain, maybe .1-.2 FTE.
How much of the current work is really project-specific?
That's the thing, it's not project-specific at all, it's whole-ODL-specific.
Can we just have a job, which turns org.opendaylight.PROJECT into an RPM
based on the recommended project layout/feature.xml analysis?
It would be an entirely new packaging/CD pipeline. *head explodes gif*-level of work.