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).

 

Best Regards,

An Ho

 

 

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.

Thanks,
Robert