Hi, I'm always wondering why we have 2 projects for Openflow southbound. I believe OpenflowJava should stay at least for the Nitrogen release (may be with deprecated Tag). Same time we can start move the OpenflowJava code under OpenflowPlugin and do some factorization and cleaning to it such as remove all config subsystem classes and configurations (I can help on that).
BR On Thu, Jun 8, 2017 at 1:50 PM, Andrew Grimberg < [email protected]> wrote: > On 06/07/2017 05:21 PM, Abhijit Kumbhare wrote: > > Just an FYI IIRC this has happened at least once already. Additionally, > from a different point of view it's similar to the project spin-outs > we've done in the past. > > --[snip]-- > > > Challenges / open questions: > > 1) How do we retain history for the OpenFlow Java code for code done > > before the code movement? *The IT experts may have some ideas on this - > > Thanh, Anil B, Andrew?* Also is there a way to subsume a project into > > another project or merge the repos? > > One obvious solution, we can just keep the OpenFlow Java Library repo > > still active - even if OpenFlow Java Library does not participate in > > future simultaneous releases. > > We would not delete the old repo, it would just become a read-only > archived repo. > > My suggestion would be to do the following: > > * Copy the HEAD of the code base being merged into the target project > > * Make the commit message state where it is coming from and the SHA of > the commit it is being taken from (in case the HEAD moves after that for > some reason) > > * Request that LF lock the origination repository > > > 2) How do handle the documentation of the 2 projects? Just move the > > OpenFlow Java documentation inside the developer guide under OFP > > documentation? > > I would think this would be the correct method. > > > 3) How do we handle the inactive committers of OpenFlow Java Library? If > > we keep OpenFlow Java Library project active without participating in > > simultaneous release - we likely do not have to address this problem. > > I would think that cleaning up the committer lists before this would be > a paramount issue. Then the committers can formally vote to bring the > old project into archive status so that we have a proper for the > read-only / archive state of the project. > > After that upon the code being brought into the other project, elevating > anyone to committer that needs to be would just follow the standard > procedures, though you would be able to point at history in the archived > project as well for making the elevation case. > > -Andy- > > -- > Andrew J Grimberg > Lead, IT Release Engineering > The Linux Foundation > > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
