On Sun, Feb 16, 2014 at 6:13 AM, Sandro Mani <manisan...@gmail.com> wrote:
> > On 16.02.2014 04:00, Richard Shaw wrote: > > On Sat, Feb 15, 2014 at 4:09 PM, Sandro Mani <manisan...@gmail.com>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. > > 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. > 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. > > 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. > 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
