|
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. * 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.
Daniel
On Fri, Sep 7, 2018 at 2:09 PM An Ho < An.Ho@...> wrote:
As discussed on Thursday’s Integration Meeting, we should consider killing off the “Common Distribution” and supporting only the “Managed Distribution” so that we can scale. Self Managed projects are free to release
their own Per-Use-Case Distributions according to their own schedule.
https://docs.google.com/presentation/d/15JP_n9t1RBQ3RhI39eFpYvz3gsY5ItleBw-l5qqvnfg
We all love and appreciate the spectacular and tremendous effort by Luis Gomez to help Self Managed projects at the last 96 hours before release (on Labor Day Weekend), but our release plan should scale without relying
on one individual.
Feedback welcome and lets discuss more at the next integration call.
Best Regards,
An Ho
|
|
|
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... * 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? How much of the current work is really project-specific? Can we just have a job, which turns org.opendaylight.PROJECT into an RPM based on the recommended project layout/feature.xml analysis? Thanks, Robert
|
|
|
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
|
|
|
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
toggle quoted message
Show quoted text
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
|
|
|
On Thu, Oct 18, 2018 at 7:15 PM An Ho < An.Ho@...> wrote:
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). +1
This would also be a nice addition to the stick/carrots - projects who are able to live up to the requirements of the MR would get a very significant extra benefit, and failing to do so would be a significant penalty.
Daniel
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
|
|
|
