Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [technology-pmc] [CQ 8940] HDF5 1.8.14
Marcel,

Thanks for the great questions. My answers are below.

I share your opinion that there is no need to put it at Eclipse.org if it isn't used there and that was why I wanted to ask about it.

On Fri, Apr 10, 2015 at 11:03 AM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:
Hi Jay,

summarizing just to see I got it right.

The java library is used by code at eclipse.org. As such it will be published under EPL and needs a full IP check.

The c++ library is not used by *any* code hosted at eclipse.org - and likely won’t be use in the near future.


Yes, the Java library is used by our project and some others that are coming in through the Science Working Group.

The C++ HDF5 library, as far as I know, would only be used by the C++ code in ICE's repo to write files that ICE can read. The C++ HDF5 library and the library for ICE would never be used by any code hosted at Eclipse.org, including ICE.

 

A couple more questions:

Who is maintaining that c++ code now and in the future?

The ICE team maintains it and we will continue to maintain it for the foreseeable future.
 
Where is the c++ code built?

The C++ code is built and linked into C/C++ or Fortran simulation codes on high-performance computing hardware. For example, if I am using a large cluster to do a simulation, then I would download ICE repo, compile the C++ code (not the Java), link to the resulting library and use it to write a file that ICE can read as my simulation runs. 
 
Where do your users expect to download the c++ code?

No where in particular. Getting it at the same repo would be purely out of convenience from their perspective. 

To be honest, most of our sophisticated build scripts in the DOE space pull repos or download tarballs on behalf of the user so that they don't have to download it themselves.
 
Under which license should the c++ code be published?

I actually think that this might be the straw that breaks the camel's back because it probably needs to be published under a New BSD license or EDL. If we released it with the EPL, those people who compiled it and linked it into their product may actually have further license problems if they have GPL pieces in their stack. I don't about that for sure though.

I have previously inquired about releasing code under EDL and was told it would have to be taken to the board, if I remember correctly.
 
Who will use the c++ library  - and not use the java library? And the other way around?

They will be used together. Someone will use the C++ library in their simulation code to write files that are then read by the Java library, (and possibly by a different user), in ICE.
 
Are there any IP conflicts you can already see (e.g. because of some c libraries you use)?


I think there may be a problem with the SZip license because it has commercial vs. non-commercial clauses.
 

My first thought was that if (i) it’s maintained by the same team and (ii) your users would expect it download it from the same site as ICE and (iii) the library should be published under EPL/EDL I’d put it to eclipse. But this decision would be mostly driven by “consistency reasons”. IMHO there is no need to put the C++ code to eclipse.org if you don’t use it there.


This consistency is what I was originally driving for on our old Sourceforge.net project. However, the only thing I see going for it at this point is that my team maintains it. Users wouldn't necessarily expect to get it from the ICE repo and it probably should be published under EDL/New BSD.

My answers to these questions really have me convinced that it should go somewhere else...

Jay

 
Marcel




On 10 Apr 2015, at 15:50, Jay Jay Billings <jayjaybillings@xxxxxxxxx> wrote:

Everyone,

I would appreciate your guidance on the discussion below.

Here is a brief summary. We are sorting out our CQs for ICE so that we can start to prepare for a release.

Here's an excerpt from the discussion. Keep in mind that there are two different versions of HDF5: "HDF-Java" is the Java version and "HDF5" is the C++ version. They do the same thing, but are just implementations in different languages.

We have two different types of HDF in ICE; HDF5 and HDF-Java. HDF-Java is what we need for the Eclipse RCP-based part of ICE. However, we  have a separate C++ library that is used by C/C++ and Fortran codes to write files that are read by our RCP side and this is where the requirement
for HDF5 comes from. It actually requires HDF5 to compile, so I now believe it may be more than a Workswith CQ.

That being said, I am thinking that it may actually be better to remove that C++ code from the ICE repo and release it as a completely separate
C++ code/project. My thinking here is that it is really a separate project - separate scope, separate language (and therefore build), separate user base, etc. We don't even require it to compile or use our RCP-based code. Thus it seems to me that it is really a separate project and it - and its HDF5 dependency - should go somewhere else.

What do you think?

Jay

---------- Forwarded message ----------
From: Jay Jay Billings <billingsjj@xxxxxxxx>
Date: Fri, Apr 10, 2015 at 9:44 AM
Subject: Re: FW: [CQ 8940] HDF5 1.8.14
To: Sharon Corbett <sharon.corbett@xxxxxxxxxxx>
Cc: "Wojtowicz, Anna" <wojtowicza@xxxxxxxx>, emo-ip-team@xxxxxxxxxxx, "jayjaybillings@xxxxxxxxx" <jayjaybillings@xxxxxxxxx>


Sharon,

I'll look into that. Thanks.

Jay

On 04/10/2015 09:34 AM, Sharon Corbett wrote:
Hi Jay;

Thanks very much for the details.  Unfortunately, questions concerning
dependencies are better suited to be answered by the project's PMC and/or
Mentors.

May we suggest you ask for their input via the PMC Mailing List.

Hope that helps.
Sharon

-----Original Message-----
From: Jay Jay Billings [mailto:bkj@xxxxxxxx]
 Sent: April-09-15 4:54 PM
To: Sharon Corbett
Cc: 'Wojtowicz, Anna'; 'Billings, Jay Jay'; emo-ip-team@xxxxxxxxxxx
Subject: RE: FW: [CQ 8940] HDF5 1.8.14

Sharon,

 I think they all remain as is, but maybe we don't need the native HDF5
libraries.

What do you think? Should I move that C++-based "part" into another project
given it is essentially separate (but just riding in the repo).

Jay

On Thu, 9 Apr 2015, Sharon Corbett wrote:

Thanks Ann;

Just to confirm; all CQs remain as is with a requirement to
redistribute, correct?
Thanks,
Sharon


-----Original Message-----
From: Wojtowicz, Anna [mailto:wojtowicza@xxxxxxxx]
Sent: April-09-15 12:41 PM
To: Sharon Corbett
 Cc: Billings, Jay Jay; emo-ip-team@xxxxxxxxxxx
Subject: RE: FW: [CQ 8940] HDF5 1.8.14

Sharon,

 After conferring with Jay, we won't require the user to install the
full HDF-Java binary. Instead, we've decided for now we will
distribute the 5 ncsa  packages listed in the CQ, and the necessary
DLL/SO libraries. This way the user doesn't have to download anything,
and we can avoid submitting the entire HDF-Java package for review. So
we'd like to proceed with the HDF-Java CQ in its current state.


Anna

-----Original Message-----
From: Jay Jay Billings [mailto:bkj@xxxxxxxx]
Sent: Thursday, April 09, 2015 9:28 AM
To: Sharon Corbett
Cc: Billings, Jay Jay; Wojtowicz, Anna; emo-ip-team@xxxxxxxxxxx
Subject: RE: FW: [CQ 8940] HDF5 1.8.14

Sharon,

Thanks for the guidance!

SZip and Zlib are required by HDF5.

We actually need to ship part of HDF-Java with ICE *and* have them
install the full HDF-Java package. It is a bit complicated but
essentially there are Java pieces that we need to include in ICE and
JNI+Native libraries that the user needs to install.

The VisIt Java Client is something that we need to ship with ICE as well.
It was originally developed as part of NiCE, (the initial
contribution), but by another National Laboratory. When we moved to
Eclipse, they elected to move that code to GitHub.

I realized after talking to Anna late yesterday that the situation
with
HDF5 may be a little more complicated than a Workswith CQ. We have two
different types of HDF in ICE; HDF5 and HDF-Java. HDF-Java is what we
need for the Eclipse RCP-based part of ICE. However, we have a
separate C++ library that is used by C/C++ and Fortran codes to write
files that are read by our RCP side and this is where the requirement
for HDF5 comes from. It actually requires HDF5 to compile, so I now
believe it may be more than a Workswith CQ.

That being said, I am thinking that it may actually be better to
remove that
C++ code from the ICE repo and release it as a completely separate
C++ code. My

thinking here is that it is really a separate project - separate
scope, separate language (and therefore build), separate user base, etc.
We don't even require it to compile our RCP-based code. Thus it seems
to me that it is really a separate project and it - and its HDF5
dependency - should go somewhere else.

What do you think?

Jay

On Thu, 9 Apr 2015, Sharon Corbett wrote:

Anna and Jay;

Thanks that is very helpful indeed.  Yes, if the CQ qualifies as a
Workswith dependency [1], we can modify the CQ accordingly. What
needs to happen after we perform that modification is for the PMC to
discuss and vote on the Workswith designation.  Following that
discussion/vote, we process the CQ accordingly.  For Workswith
dependencies we do not perform due diligence review.

I'll make that change now to CQ 8940.  Can you let us know if any of
the other remaining CQs fall into that category as well; specifically
HDF-Java 2.10.1.

Other remaining CQs; SZip, Zlib, and VisIt Java Client.

[1]
https://eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3r
d
_Party
_Dependencies_Final.pdf

Kind Regards,
Sharon


-----Original Message-----
From: Jay J. Billings [mailto:billingsjj@xxxxxxxx]
Sent: April-08-15 5:09 PM
To: Wojtowicz, Anna; emo-ip-team@xxxxxxxxxxx
Subject: Re: FW: [CQ 8940] HDF5 1.8.14

Anna,

I think that we need to file a CQ just to make it clear that we work
with HDF5.

I have added the IP team back to the list to get some help on that.
Sharon, is that true? If it is an optional package that they may
download and use at their leisure that we do not need to distribute
do we only need to file a "Works With" CQ?

Thanks,
Jay

On 04/08/2015 03:43 PM, Wojtowicz, Anna wrote:
Should we proceed with this? We never intended to distribute HDF5
but let
the user download it for themselves, meaning we can't exclude
anything from the CQ...
Anna

-----Original Message-----
From: emo-ip-team@xxxxxxxxxxx [mailto:emo-ip-team@eclipse.org]
Sent: Wednesday, April 08, 2015 3:40 PM
To: Wojtowicz, Anna
Subject: [CQ 8940] HDF5 1.8.14

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=8940


Sharon Corbett <sharon.corbett@xxxxxxxxxxx> changed:

             What    |Removed                     |Added

---------------------------------------------------------------------
-
------
             Severity|new                         |awaiting_committer




--- Comment #7 from Sharon Corbett <sharon.corbett@xxxxxxxxxxx>
2015-04-08 15:39:37 --- Hi Anna:
Can you please confirm the project really intends to distribute all
65 MB
of this content.  I note the inclusion of the following directories:
bin
perform
tools

Thanks for the confirm.

Sharon



Auto-Generated Text:  IPTeam awaiting response from Committer.


--
Configure CQmail:
http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: ------- You are on the
CC
list for the CQ.
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings









--
Jay Jay Billings
Oak Ridge National Laboratory
Telephone: (865) 272-9420
Email:billingsjj@xxxxxxxx
Twitter Handle: @jayjaybillings




--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/technology-pmc

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940


_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/technology-pmc



--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings

Back to the top