On Sun, Feb 16, 2014 at 6:13 AM, Sandro Mani <manisandro@xxxxxxxxx> wrote:
My goal was to try and keep the spec files small, one spec for all the salome components would have been huge. Also, like this I guess it is easier to proceed step by step, instead of needing to package the whole thing in one go. Debian also seems to do it this way.
On 16.02.2014 04:00, Richard Shaw wrote:
On Sat, Feb 15, 2014 at 4:09 PM, Sandro Mani <manisandro@xxxxxxxxx> wrote:
The salome-kernel srpm is here [1]. I see now that I actually didn't completely finish salome-gui...
Interesting... You're extracting just the kernel module... Maybe it's not worth the trouble but I was working with the whole source, which is now at version 7.3.0.
Maybe it is too much to bite off at once but if all the sources are packaged separately it seems like it would be more difficult to keep everything in sync.
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.
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.
I didn't need the omniORB patch but I did have to do a quick package of omniORBpy which is under review:
Up to you, it's not my review I just happened to find it while checking for current review requests before submitting my own.
As a general note, as stated before, until the end of the month I'm kinda pressed for time, but maybe a bit in the evenings and surely after that I'm happy to also work on this. Last I worked on this, I noted the following list of components:
kernel
gui
geom
med
smesh
smesh-plugin-blsurf
smesh-plugin-ghs3d
smesh-plugin-ghs3dprl
smesh-plugin-hexablock
smesh-plugin-hexotic
smesh-plugin-netgen
visu
yacs
atomgen
atomic
atomsolv
hexablock
homard
jobmanager
paravis
randomizer
sierpinsky
devel-hxx2salome
devel-yacsgen
data-samples
tutorials
doc
Which components are you planning to work on?
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?) then I could probably get a temporary bundling exception.
Thanks,
Richard
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
