1. z.archive.openflowjava-dev@lists.opendaylight.org
  2. Messages
   Date   
Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

Robert Varga <nite@...>
 

On 27/06/17 12:52, Tomáš Slušný wrote:
Hello Robert,


I can import OpenFlowJava using `git subtree` to not lose history (and I
actually have it already prepared in my local repository, because that
was first thing I tried), but then it would create Gerrit patch for each
OpenFlowJava commit if I am not wrong. Or is there another method of
doing this merge?
What we have done in the past was to ask Linux Foundation admins to
populate the repository, side-stepping gerrit. We have done this for
mdsal and netconf at least.

I am not sure if the same effect is doable with gerrit.

Regards,
Robert

?
signature.asc

Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

Jozef Bacigál <jozef.bacigal@...>
 

HI all, 


just thoughts 


we can still keep the history in frozen project, with the description on the first commit that the projects were merged together. And with the information where the old history can be found. 

If I am not wrong merging two repositories with git subtree creates a huge amount of merging commits ?


Jozef

Od: Tomáš Slušný <tomas.slusny@...>
Odoslané: utorok, 27. júna 2017 12:52:45
Komu: Robert Varga; release@...
Kópia: openflowjava-dev@...; tsc@...; Michal Rehák; openflowplugin-dev
Predmet: Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen
 

Hello Robert,


I can import OpenFlowJava using `git subtree` to not lose history (and I actually have it already prepared in my local repository, because that was first thing I tried), but then it would create Gerrit patch for each OpenFlowJava commit if I am not wrong. Or is there another method of doing this merge?


Regards,

Tomas Slusny


Od: Robert Varga <nite@...>
Odoslané: utorok, 27. júna 2017 12:23
Komu: Tomáš Slušný; release@...
Kópia: openflowjava-dev@...; Michal Rehák; openflowplugin-dev; Abhijit Kumbhare; tsc@...
Predmet: Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen
 
On 27/06/17 12:13, Tomáš Slušný wrote:
>
>       https://wiki.opendaylight.org/view/Weather#OpenFlowJava_being_merged_into_OpenFlowPlugin_in_Nitrogen
>
>
>       OpenFlowJava being merged into OpenFlowPlugin in Nitrogen[edit
>       <https://wiki.opendaylight.org/index.php?title=Weather&action=edit&section=9>]
>
>   * *Description:*
>
> Merge OpenFlowJava into OpenFlowPlugin repository to decrease the
> logistics related to the OpenFlow southbound development.
>
>   * *Reported By:* Tomas Slusny, Email: tomas.slusny@..., IRC:
>     tomasslusny
>   * *Reported On:* 06/27/2017
>   * *Links to opened bugs:*
>       o https://bugs.opendaylight.org/show_bug.cgi?id=8747
>   * *Links to patches:*
>       o https://git.opendaylight.org/gerrit/#/c/59528/
>       o https://git.opendaylight.org/gerrit/#/c/59529/
>       o https://git.opendaylight.org/gerrit/#/c/59550/

Hello,

rather than copying the code, can you please have LF import the
repository? That way we do not lose history -- which is very important.

Regards,
Robert

 
Tomáš Slušný
Software Developer
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / tomas.slusny@...
WEB / https://pantheon.tech
 
 
 
Jozef Bacigál
Senior Software Engineer
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / jozef.bacigal@...
WEB / https://pantheon.tech
 
 
Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

Tomáš Slušný <tomas.slusny@...>
 

Hello Robert,


I can import OpenFlowJava using `git subtree` to not lose history (and I actually have it already prepared in my local repository, because that was first thing I tried), but then it would create Gerrit patch for each OpenFlowJava commit if I am not wrong. Or is there another method of doing this merge?


Regards,

Tomas Slusny


Od: Robert Varga <nite@...>
Odoslané: utorok, 27. júna 2017 12:23
Komu: Tomáš Slušný; release@...
Kópia: openflowjava-dev@...; Michal Rehák; openflowplugin-dev; Abhijit Kumbhare; tsc@...
Predmet: Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen
 
On 27/06/17 12:13, Tomáš Slušný wrote:
>
>       https://wiki.opendaylight.org/view/Weather#OpenFlowJava_being_merged_into_OpenFlowPlugin_in_Nitrogen
>
>
>       OpenFlowJava being merged into OpenFlowPlugin in Nitrogen[edit
>       <https://wiki.opendaylight.org/index.php?title=Weather&action=edit&section=9>]
>
>   * *Description:*
>
> Merge OpenFlowJava into OpenFlowPlugin repository to decrease the
> logistics related to the OpenFlow southbound development.
>
>   * *Reported By:* Tomas Slusny, Email: tomas.slusny@..., IRC:
>     tomasslusny
>   * *Reported On:* 06/27/2017
>   * *Links to opened bugs:*
>       o https://bugs.opendaylight.org/show_bug.cgi?id=8747
>   * *Links to patches:*
>       o https://git.opendaylight.org/gerrit/#/c/59528/
>       o https://git.opendaylight.org/gerrit/#/c/59529/
>       o https://git.opendaylight.org/gerrit/#/c/59550/

Hello,

rather than copying the code, can you please have LF import the
repository? That way we do not lose history -- which is very important.

Regards,
Robert

 
Tomáš Slušný
Software Developer
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / tomas.slusny@...
WEB / https://pantheon.tech
 
 
Re: [release] WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

Robert Varga <nite@...>
 

On 27/06/17 12:13, Tomáš Slušný wrote:

https://wiki.opendaylight.org/view/Weather#OpenFlowJava_being_merged_into_OpenFlowPlugin_in_Nitrogen


OpenFlowJava being merged into OpenFlowPlugin in Nitrogen[edit
<https://wiki.opendaylight.org/index.php?title=Weather&action=edit§ion=9>]

* *Description:*

Merge OpenFlowJava into OpenFlowPlugin repository to decrease the
logistics related to the OpenFlow southbound development.

* *Reported By:* Tomas Slusny, Email: tomas.slusny@..., IRC:
tomasslusny
* *Reported On:* 06/27/2017
* *Links to opened bugs:*
o https://bugs.opendaylight.org/show_bug.cgi?id=8747
* *Links to patches:*
o https://git.opendaylight.org/gerrit/#/c/59528/
o https://git.opendaylight.org/gerrit/#/c/59529/
o https://git.opendaylight.org/gerrit/#/c/59550/
Hello,

rather than copying the code, can you please have LF import the
repository? That way we do not lose history -- which is very important.

Regards,
Robert

?
signature.asc

WEATHER - OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

Tomáš Slušný <tomas.slusny@...>
 

https://wiki.opendaylight.org/view/Weather#OpenFlowJava_being_merged_into_OpenFlowPlugin_in_Nitrogen

OpenFlowJava being merged into OpenFlowPlugin in Nitrogen[edit]

  • Description:

Merge OpenFlowJava into OpenFlowPlugin repository to decrease the logistics related to the OpenFlow southbound development.


 
Tomáš Slušný
Software Developer
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / tomas.slusny@...
WEB / https://pantheon.tech
 
 
OPENFLOWJAVA Nitrogen Status

an.ho@huawei.com
 

Hi Michal Rehak and OPENFLOWJAVA Team,

We would like to express our appreciation for your contribution to the Carbon Simultaneous Release and the wonderful innovations your team has brought to the OpenDaylight Project and its community.

We have not heard from your project regarding your intent to participate in the Nitrogen Simultaneous Release [1] which was due on June 21, 2017 [2]. Please take a moment to confirm if your project intends to drop from the Nitrogen Simultaneous Release. We will assume your project does not intend to participate in the Nitrogen Simultaneous Release if we do not hear back by the end of this week.

Please note that projects participating in the Nitrogen Simultaneous Release are required to complete the Nitrogen Simultaneous Release Plan Requirements [3] as well as the Nitrogen Karaf 4 Migration Requirements [5], including:

* local karaf 4 distribution: projects build local karaf 4 distribution
** create karaf 4 features and local karaf 4 distribution
** test, and identify blocking issues
** examples: https://git.opendaylight.org/gerrit/#/c/55160/ (support only karaf 4) or https://git.opendaylight.org/gerrit/#/c/58726/ (support karaf 3 and karaf 4)
** create bugzilla issue such as https://bugs.opendaylight.org/show_bug.cgi?id=8638 and make it block https://bugs.opendaylight.org/show_bug.cgi?id=4219
* odlparent version 2: projects migrate themselves to odlparent version 2.0.0
** This means removing your Karaf 3 features (because odlparent 2.0.0 will not support Karaf 3 anymore)
** projects should make some minor adjustments in the code related to the switch to a newer Guava version.
* add to integration distribution: projects to add their karaf 4 features to integration distribution as per https://wiki.opendaylight.org/view/Karaf_4_migration#Step_7:_add_your_karaf_4_features_to_distribution

Best Regards,
An Ho

[1] https://lists.opendaylight.org/pipermail/release/2017-June/011123.html
[2] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Schedule
[3] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Requirements_for_Participation
[4] https://wiki.opendaylight.org/view/Simultaneous_Release/Nitrogen/Karaf#Nitrogen_Project_Requirements
Re: OpenFlow Plugin and OpenFlow Java Library

Abhijit Kumbhare
 

Thanks Sam! We may have some questions as we go further into the process.

On Thu, Jun 8, 2017 at 1:00 PM Sam Hague <shague@...> wrote:
On Wed, Jun 7, 2017 at 8:21 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:
> Hi folks,
>
> We have 2 projects for OpenFlow - OpenFlow Plugin (connection handling,
> state management, apps like the FRM, etc.) & OpenFlow Java Library (library
> for the low level wire protocol implementation). This increases the
> logistics related to the OpenFlow southbound development (done in two
> places) and project reporting overhead. The other southbounds like OVSDB,
> NetConf, etc. do not have two different projects - even if some of them may
> have a similar split internally (plugin & library).
>
> Also more importantly currently most community activity
> (meetings/discussions for the new features) happen in the OpenFlow Plugin
> community even though the implementation needs to be done in OF Plugin and
> OFJ Library. Also going forward OFJ may have only a single active committer
> (Jozef Bacigal).
>
> So some of us feel Nitrogen might be a good time to unify these two
> projects.
>
> The current thought:
>   Move all the code from OpenFlow Java Library to the OpenFlow Plugin.
>
> Advantages:
> 1) This may not need a lot of work.
> 2) All active OpenFlow Java committers are also committers on OpenFlow
> Plugin.
> 3) Since we are not creating a project & if we do not add any new committers
> - this may not even need a TSC approval (but we will work with the TSC when
> we have decided the exact action).
>
> 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?

We kept history when we split ovsdb/netvirt and then merged netvirt
and vpnservice. The flow Andy used copied all the files into NetVirt
and the history was kept intact. I think I came up with the commands
to use and Andy did the work - but I can't find those emails right
now.

You should also stop the jobs running for the old openflowjava repo
and migrate them to use openflowplugin repo.

>    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.
> 2) How do handle the documentation of the 2 projects? Just move the OpenFlow
> Java documentation inside the developer guide under OFP documentation?

Yes, this is what we did - just pulled in the relvant docs to netvirt.

> 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.
>
> If you have thoughts/suggestions/objections - please reply to this email.
>
> Thanks,
> Abhijit
>
>
> _______________________________________________
> openflowjava-dev mailing list
> openflowjava-dev@...
> https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
>
Re: OpenFlow Plugin and OpenFlow Java Library

Sam Hague
 

On Wed, Jun 7, 2017 at 8:21 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Hi folks,

We have 2 projects for OpenFlow - OpenFlow Plugin (connection handling,
state management, apps like the FRM, etc.) & OpenFlow Java Library (library
for the low level wire protocol implementation). This increases the
logistics related to the OpenFlow southbound development (done in two
places) and project reporting overhead. The other southbounds like OVSDB,
NetConf, etc. do not have two different projects - even if some of them may
have a similar split internally (plugin & library).

Also more importantly currently most community activity
(meetings/discussions for the new features) happen in the OpenFlow Plugin
community even though the implementation needs to be done in OF Plugin and
OFJ Library. Also going forward OFJ may have only a single active committer
(Jozef Bacigal).

So some of us feel Nitrogen might be a good time to unify these two
projects.

The current thought:
Move all the code from OpenFlow Java Library to the OpenFlow Plugin.

Advantages:
1) This may not need a lot of work.
2) All active OpenFlow Java committers are also committers on OpenFlow
Plugin.
3) Since we are not creating a project & if we do not add any new committers
- this may not even need a TSC approval (but we will work with the TSC when
we have decided the exact action).

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?
We kept history when we split ovsdb/netvirt and then merged netvirt
and vpnservice. The flow Andy used copied all the files into NetVirt
and the history was kept intact. I think I came up with the commands
to use and Andy did the work - but I can't find those emails right
now.

You should also stop the jobs running for the old openflowjava repo
and migrate them to use openflowplugin repo.

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.
2) How do handle the documentation of the 2 projects? Just move the OpenFlow
Java documentation inside the developer guide under OFP documentation?
Yes, this is what we did - just pulled in the relvant docs to netvirt.

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.

If you have thoughts/suggestions/objections - please reply to this email.

Thanks,
Abhijit


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
Re: [openflowplugin-dev] OpenFlow Plugin and OpenFlow Java Library

Abhijit Kumbhare
 

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 <m.elserngawy@...> 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 <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
Re: OpenFlow Plugin and OpenFlow Java Library

Abhijit Kumbhare
 

Thanks Andy! Lot of good advice there - and a good blueprint to follow.

On Thu, Jun 8, 2017 at 10:50 AM, 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
Re: [openflowplugin-dev] OpenFlow Plugin and OpenFlow Java Library

Mohamed ElSerngawy
 

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@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
Re: OpenFlow Plugin and OpenFlow Java Library

Andrew Grimberg <agrimberg@...>
 

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

?
signature.asc

Bug 8640 - Karaf4 NullPointerException at org.opendaylight.openflowjava.protocol.impl.core.SwitchConnectionProviderImpl.createAndConfigureServer

Michael Vorburger <vorburger@...>
 

Hello good people of openflowjava-dev,

you may want to have a closer look at https://bugs.opendaylight.org/show_bug.cgi?id=8640 ?

Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch
OpenFlow Plugin and OpenFlow Java Library

Abhijit Kumbhare
 

Hi folks,

We have 2 projects for OpenFlow - OpenFlow Plugin (connection handling, state management, apps like the FRM, etc.) & OpenFlow Java Library (library for the low level wire protocol implementation). This increases the logistics related to the OpenFlow southbound development (done in two places) and project reporting overhead. The other southbounds like OVSDB, NetConf, etc. do not have two different projects - even if some of them may have a similar split internally (plugin & library).
 
Also more importantly currently most community activity (meetings/discussions for the new features) happen in the OpenFlow Plugin community even though the implementation needs to be done in OF Plugin and OFJ Library. Also going forward OFJ may have only a single active committer (Jozef Bacigal). 

So some of us feel Nitrogen might be a good time to unify these two projects.

The current thought:
  Move all the code from OpenFlow Java Library to the OpenFlow Plugin.

Advantages:
1) This may not need a lot of work. 
2) All active OpenFlow Java committers are also committers on OpenFlow Plugin.
3) Since we are not creating a project & if we do not add any new committers - this may not even need a TSC approval (but we will work with the TSC when we have decided the exact action).

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. 
2) How do handle the documentation of the 2 projects? Just move the OpenFlow Java documentation inside the developer guide under OFP documentation?
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.

If you have thoughts/suggestions/objections - please reply to this email.

Thanks,
Abhijit
Re: [URGENT] OPENFLOWJAVA Carbon GO/NOGO Vote

Michal Rehák <michal.rehak@...>
 

Hi all,

my apologies, I just updated the spreadsheet for openflowjava.


Regards,

Michal



--

Michal Rehák
Software developer
Pantheon Technologies s.r.o.
Mlynské Nivy 56
821 05 Bratislava
Slovakia
Mobile:  +421 918 621 908
Mail:    michal.rehak@...
Web:     www.pantheon.tech

From: An Ho <An.Ho@...>
Sent: Wednesday, May 24, 2017 8:24:03 PM
To: Michal Rehák; Colin Dixon; Casey Cain; openflowjava-dev@...; daniel.bartos@...; michal.polkorab@...; Jozef Bacigál
Subject: [URGENT] OPENFLOWJAVA Carbon GO/NOGO Vote
 
Hi Michal Rehak and OPENFLOWJAVA Team,

We are missing your required GO/NOGO Vote.

Please vote GO/NOGO on the spreadsheet below by filling out Column B through E next to your project name:

https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1166457948

Please let us know if you are having trouble accessing the spreadsheet, in which case you may reply to this email and I can update the spreadsheet on your behalf.
 
Best Regards,
An Ho
 
[1] https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#RC3_Download

 
Michal Rehák
Technical Leader
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / michal.rehak@...
WEB / www.pantheon.tech
 
 
[URGENT] OPENFLOWJAVA Carbon GO/NOGO Vote

an.ho@huawei.com
 

Hi Michal Rehak and OPENFLOWJAVA Team,

We are missing your required GO/NOGO Vote.

Please vote GO/NOGO on the spreadsheet below by filling out Column B through E next to your project name:

https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1166457948

Please let us know if you are having trouble accessing the spreadsheet, in which case you may reply to this email and I can update the spreadsheet on your behalf.
 
Best Regards,
An Ho
 
[1] https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#RC3_Download
Re: Nomination for new Committer: Jozef Bacigal

Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES@Cisco) <mirehak@...>
 

+1 from me


Regards,
Michal



From: Daniel Bartoš <daniel.bartos@...>
Sent: Monday, May 22, 2017 11:46
To: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco); openflowjava-dev@...
Subject: RE: Nomination for new Committer: Jozef Bacigal
 

+1 for me

 

From: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco) [mailto:mirehak@...]
Sent: Monday, May 22, 2017 11:05 AM
To: openflowjava-dev@...
Subject: Nomination for new Committer: Jozef Bacigal

 

Hi ofjava committers,

the motivation for nominating Jozef Bacigal to committer on the openflowjava project is due to a considerable long history of providing value to the project through consistent high quality and valuable contributions.

 

- migration to karaf4 features

- various test utilities and scenarios contribution

- couple of bug fixes

 

I provide a link to the relevant contributions.

https://git.opendaylight.org/gerrit/#/q/project:openflowjava+owner:%22Jozef+Bacigal+%253Cjozef.bacigal%2540pantheon.tech%253E%22+status:merged

 


Please vote +1,0,-1 on whether you would like to see him as a committer.

 

 

Thank you.

 

Regards,

Michal

 
Daniel Bartoš
Sales Manager
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / daniel.bartos@...
WEB / www.pantheon.tech
 
 
Re: Nomination for new Committer: Jozef Bacigal

Daniel Bartoš <daniel.bartos@...>
 

+1 for me

 

From: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco) [mailto:mirehak@...]
Sent: Monday, May 22, 2017 11:05 AM
To: openflowjava-dev@...
Subject: Nomination for new Committer: Jozef Bacigal

 

Hi ofjava committers,

the motivation for nominating Jozef Bacigal to committer on the openflowjava project is due to a considerable long history of providing value to the project through consistent high quality and valuable contributions.

 

- migration to karaf4 features

- various test utilities and scenarios contribution

- couple of bug fixes

 

I provide a link to the relevant contributions.

https://git.opendaylight.org/gerrit/#/q/project:openflowjava+owner:%22Jozef+Bacigal+%253Cjozef.bacigal%2540pantheon.tech%253E%22+status:merged

 


Please vote +1,0,-1 on whether you would like to see him as a committer.

 

 

Thank you.

 

Regards,

Michal

 
Daniel Bartoš
Sales Manager
 
PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111
 
MAIL / daniel.bartos@...
WEB / www.pantheon.tech
 
 
Re: Nomination for new Committer: Jozef Bacigal

Michal Polkorab <michal.polkorab@...>
 

+1 for me.

Michal Polkorab

2017-05-22 11:04 GMT+02:00 Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco) <mirehak@...>:

Hi ofjava committers,

the motivation for nominating Jozef Bacigal to committer on the openflowjava project is due to a considerable long history of providing value to the project through consistent high quality and valuable contributions.


- migration to karaf4 features

- various test utilities and scenarios contribution

- couple of bug fixes


I provide a link to the relevant contributions.

https://git.opendaylight.org/gerrit/#/q/project:openflowjava+owner:%22Jozef+Bacigal+%253Cjozef.bacigal%2540pantheon.tech%253E%22+status:merged



Please vote +1,0,-1 on whether you would like to see him as a committer.



Thank you.


Regards,

Michal


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
Nomination for new Committer: Jozef Bacigal

Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES@Cisco) <mirehak@...>
 

Hi ofjava committers,

the motivation for nominating Jozef Bacigal to committer on the openflowjava project is due to a considerable long history of providing value to the project through consistent high quality and valuable contributions.


- migration to karaf4 features

- various test utilities and scenarios contribution

- couple of bug fixes


I provide a link to the relevant contributions.

https://git.opendaylight.org/gerrit/#/q/project:openflowjava+owner:%22Jozef+Bacigal+%253Cjozef.bacigal%2540pantheon.tech%253E%22+status:merged



Please vote +1,0,-1 on whether you would like to see him as a committer.



Thank you.


Regards,

Michal
41 - 60 of 861