On Wed, Jul 26, 2017 at 6:00 PM, Colin Dixon <co...@colindixon.com> wrote:
> While I agree releasing a library as a 3rd-party package is simpler than > creating a full-on new project, it doesn't seem simpler than either (a) > putting it in a existing project and not touching the code or even (b) > leaving it in controller and not touching the code. > Agreed, I think the easiest is if we can add it to genius (or openflowplugin) and call it done. > > If we're really looking for it to be a 3rd-party library, would it be > easier to actually make it one? Host the code on github under the EPL? > Release it and literally have it not be part of ODL's infra at all? > My idea of third-party was it was still an ODL artifact in a repo, built and pushed to nexus, but we treat it like a third-party in that once that artifact is pushed we are done. We just pull the artifact in and don't manage it as a typical ODL project. > > --Colin > > On Wed, Jul 26, 2017 at 5:54 PM Anil Vishnoi <vishnoia...@gmail.com> > wrote: > >> I was looking for any existing 3 party lldp library that we can use, and >> the only one i found is from ONOS (and looks like that's pretty >> maintained). I think it's not really an option, but just want to share. >> >> https://search.maven.org/#search%7Cga%7C1%7Clldp >> >> As sam mentioned, if we can eliminate the dependency of odlparent for >> library and push it as as third party library, i think it should be >> simplest solution. >> >> On Wed, Jul 26, 2017 at 12:32 PM, Vishal Thapar < >> vishal.tha...@ericsson.com> wrote: >> >>> 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> 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] *On Behalf Of *Colin >>> Dixon >>> *Sent:* 26 July 2017 18:45 >>> *To:* Sam Hague <sha...@redhat.com>; Stephen Kitt <sk...@redhat.com> >>> *Cc:* t...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; >>> 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> wrote: >>> >>> On Fri, Jul 21, 2017 at 4:25 AM, Stephen Kitt <sk...@redhat.com> wrote: >>> >>> On Thu, 20 Jul 2017 14:35:59 -0400 >>> Tom Pantelis <tompante...@gmail.com> wrote: >>> > On Thu, Jul 20, 2017 at 1:41 PM, Robert Varga <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 >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>> >>> _______________________________________________ >>> release mailing list >>> 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 >>> >>> >> >> >> -- >> Thanks >> Anil >> _______________________________________________ >> controller-dev mailing list >> controller-dev@lists.opendaylight.org >> https://lists.opendaylight.org/mailman/listinfo/controller-dev >> > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
