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
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

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 <agrimberg@...> 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
openflowplugin-dev@...aylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev