Re: OpenCASCADE and applications depending on it

[Sandro Mani <manisandro@xxxxxxxxx>]

On 16.02.2014 20:41, Richard Shaw wrote:

On Sun, Feb 16, 2014 at 9:58 AM, Sandro Mani <manisandro@xxxxxxxxx> wrote:

On 16.02.2014 14:56, Richard Shaw wrote:

[snip]

I wonder if we could do a staged review instead, for instance, have a review request just for the kernel, then create a separate review request for smesh but make the kernel review request a blocker for it. I think this would break the reviews into manageable chucks but preserve the source as is while making sure each module gets reviewed. Otherwise we would have to get all of them reviewed at one time.

The main difference from the traditional review would be we would not need a SCM request after the first, we would just be getting the OK that the module was good and met the guidelines.

So basically in the end you would merge the spec files together into one big thing? Or possibly have one master spec with many small specs which are included with %include ?

Nothing quite that complicated. I would say the first review would be called just "salome" but in the text specify that this review is for the kernel only. The other reviews would also include the same spec but would have the additional "guts" needed for the new modules being reviewed. Since the kernel review would be a blocker to any subsequent reviews, that should keep things sufficiently serialized otherwise things could get very messy. We need to make sure that during the review cycle for the kernel that any changed required make their way into the later reviews.

Ok.

I didn't need the omniORB patch but I did have to do a quick package of omniORBpy which is under review:

https://bugzilla.redhat.com/show_bug.cgi?id=783064

Oh right, I see I also have a omniORBpy src.rpm in my work-in-progress folder, I guess I also hit that dependency down the road. Your review seems stalled, if you want I can take over.

Up to you, it's not my review I just happened to find it while checking for current review requests before submitting my own.

I've commented in BZ.

I saw that! Thanks.

 

[snip]

Of course I'd like to see the whole thing in Fedora but my immediate need is for smesh. I've got an open review for OpenCascade community edition already going and need both for FreeCAD, which currently bundles smesh. 

If we can get a RR going for the kernel and smesh (does smesh have any other dependencies?)

From my work-in-progess spec, I see
%package smesh
Summary: The Salome smesh (meshing) module
Requires: salome-gui%{?_isa} = %{version}-%{release}
Requires: salome-geom%{?_isa} = %{version}-%{release}
Requires: salome-med%{?_isa} = %{version}-%{release}

So the roadmap is basically to get python-omniORB and OCE in fedora, and then we can start moving with salome-kernel and the rest.

Sounds like a plan!

Looking at this, we don't necessarily need to do the reviews 1 for 1 per module, but perhaps make smesh and it's requirements one "review". What do you think?

Fine with me. I had a quick look at updating adapting my salome-kernel for the latest 7.3.0 release, it is mostly working, however they removed the autotools buildsystem and now it is cmake only, meaning I have to hunt down all the places again where they forgot DESTDIR in the cmake files. As it stands now, it builds ok, but fails trying to install some files in system prefix.

Sandro

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct