<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 16, 2014 at 9:58 AM, Sandro Mani <span dir="ltr"><<a href="mailto:manisandro@gmail.com" target="_blank">manisandro@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div>On 16.02.2014 14:56, Richard Shaw
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">[snip]
<div class=""><div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div></div>
</div>
</div>
</blockquote>
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 ?</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class=""><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">I didn't need the omniORB
patch but I did have to do a quick package of
omniORBpy which is under review:</div>
<div class="gmail_extra"><a href="https://bugzilla.redhat.com/show_bug.cgi?id=783064" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=783064</a><br>
</div>
</div>
</blockquote>
</div>
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.</div>
</blockquote>
<div><br>
</div>
<div>Up to you, it's not my review I just happened to find
it while checking for current review requests before
submitting my own.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote></div>
I've commented in BZ.<br></div></blockquote><div><br></div><div>I saw that! Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">[snip]</div>
</blockquote><div class="">
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>If we can get a RR going for the kernel and smesh (does
smesh have any other dependencies?)</div>
</div></div>
</div>
</div>
</blockquote>
From my work-in-progess spec, I see<br>
%package smesh<br>
Summary: The Salome smesh (meshing) module<br>
Requires: salome-gui%{?_isa} = %{version}-%{release}<br>
Requires: salome-geom%{?_isa} = %{version}-%{release}<br>
Requires: salome-med%{?_isa} = %{version}-%{release}<br>
<br>
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.<br></div></blockquote><div><br></div><div>Sounds like a plan!</div><div><br></div><div>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? </div>
<div><br></div><div>Thanks,</div><div>Richard</div></div></div></div>