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
