This may work if liblldp is part of genius-api feature set. Is there any Impl code in LLDP that could cause problems?
Regards, Vishal. From: Sam Hague [mailto:sha...@redhat.com] Sent: 26 July 2017 23:47 To: Vishal Thapar <vishal.tha...@ericsson.com> Cc: Colin Dixon <co...@colindixon.com>; Stephen Kitt <sk...@redhat.com>; t...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; rele...@lists.opendaylight.org; genius-...@lists.opendaylight.org Subject: Re: [controller-dev] [release] [OpenDaylight TSC] Moving lldp code from controller On Wed, Jul 26, 2017 at 9:56 AM, Vishal Thapar <vishal.tha...@ericsson.com<mailto:vishal.tha...@ericsson.com>> wrote: As one of the consumers, Genius would be ready to take it in. We’re planning to discuss/vote-on this in tomorrow’s Genius meeting. Before we put this up for vote in Genius, we’d like to know expectations from Genius should we decide to host it. I thought this produced a cycle. openflowplugin uses liblldp and genius uses openflowplugin. Or is that not a concern? Regards, Vishal. From: controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org> [mailto:controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>] On Behalf Of Colin Dixon Sent: 26 July 2017 18:45 To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>; Stephen Kitt <sk...@redhat.com<mailto:sk...@redhat.com>> Cc: t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>; rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org> Subject: Re: [controller-dev] [release] [OpenDaylight TSC] Moving lldp code from controller Just to play devil's advocate, new projects for such things have a significant set of additional overheads: * during releases, release engineering staff have to track it * added periodic merge jobs and integration jobs with spinup time that adds more load to our infra * higher risk of abandonment by loss or committers I guess in this case, if we expect the project to basically only ever release once and it's pulling in of order versions of ODL parent is either OK or eliminated, that should mitigate the first two pretty significantly. Note that we'd also likely need to make sure other projects pull it in and test it in an automated fashion to avoid regressions. It still doesn't fix the risk of abandonment. --Colin On Fri, Jul 21, 2017 at 8:28 AM Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>> wrote: On Fri, Jul 21, 2017 at 4:25 AM, Stephen Kitt <sk...@redhat.com<mailto:sk...@redhat.com>> wrote: On Thu, 20 Jul 2017 14:35:59 -0400 Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>> wrote: > On Thu, Jul 20, 2017 at 1:41 PM, Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> > wrote: > > since we would like to make some progress in the great controller > > purge project, we need to decide what to do about liblldp. [...] > > Do you think this really warrants a separate project? I recall > mention of merging it into another project - would genius or > infrautils fit? I think it does warrant a separate project, from a maintenance and lifecycle perspective. liblldp is also quite different from all the other projects in OpenDaylight, so merging it into another project would just add a bunch of code to whatever target we pick, code that the host project doesn’t really care about in all likelihood. I also wouldn’t want infrautils to end up being the dumping ground for ODL... Of course this means a certain amount of bureaucracy, which is rather unfortunate. Perhaps we can continue with the collapsed milestones and lack of read-out requests for future development cycles ;-). Agreed, this seems best for projects like this. If we could create a lightweight process such that the only real work is the initial work to get liblldp into a project and building: approve it, make repo, setup jenkins jobs, and artifacts pushed. From there it is on autopilot. It is automatically include in the release if others are using it - so no milestone readouts or other maintenance. Of course if there are breakages then we need to fix them. But effectively, this becomes like a third-party artifact. If we can get something like that together, I would volunteer to take ownership (PTL and committer and a couple others) and get it into a project and building. Regards, Stephen _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ release mailing list rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/release
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
