On Wed, Jul 26, 2017 at 9:14 AM, Colin Dixon <co...@colindixon.com> wrote:
> 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 > Agreed and some of the points were where I was hoping we could treat liblldp as a third-part artifact. We really just need some artifacts in nexus for the other projects to pull. The code hasn't changed in two years so the only changes going forward would hopefully just be odlparent type changes. From that the main cost was startup cost to create the new project, move the code and get a job going. Those steps can be completed quickly. After that this goes into auto-pilot mode with no tracking if nothing changes, no milestone updates, etc. > > 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. > The csit for all the projects would provide validation, right? > > It still doesn't fix the risk of abandonment. > Yeah. That's why I added three committers on the proposal to have people involved if needed. We should add others also. Technically the project is abandoned now. It is in controller but I don't think the original authors are committers in controller. > > --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
