Thanks Andy! Lot of good advice there - and a good blueprint to follow. On Thu, Jun 8, 2017 at 10:50 AM, 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
