We will have to check out the best way forward without disruption to the OpenFlow Plugin consumers - be it in Nitrogen or some other time.
On Thu, Jun 8, 2017 at 11:12 AM, Mohamed El-Serngawy <[email protected] > wrote: > 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
