<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 14.08.2017 um 11:46 schrieb Julien
Isorce:<br>
</div>
<blockquote type="cite"
cite="mid:CAHWPjbU3EN3X8vz+zTCZLf1h1OvhtG969Sa_2nAArP6QaZNamg@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Hi Leo,
<div><br>
</div>
<div>><span style="font-size:12.8px">It would be better if
you can extract the common code between bellagio and tizonia
to avoid the duplication.</span><br>
<div><br>
</div>
<div>This is something Gurkirpal and me discussed, like having
state_trackers/omx/common, state_trackers/omx/bellagio,
state_trackers/omx/tizonia. To anticipate that Gurkirpal
sent an email <a
href="https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html"
target="_blank" moz-do-not-send="true">https://www.mail-<wbr>archive.com/mesa-dev@lists.<wbr>freedesktop.org/msg153562.html</a>
during the Community Bonding period in May (a few weeks from
the date (early May) students are officially accepted to the
date (end May) where student actually starts working)</div>
<div><br>
</div>
<div>The problem with the directory layout above is that it
would look like it will be built together in the same shared
library. This is not good because it is suppose to
export OMX_ComponentInit for each target. Of course this
would still be possible to have 2 shared libs but I believe
in state_trackers dir, all sub dir are for one target. Also
we were afraid that there would be other limitations so we
decided to go for a separate directory.</div>
<div>And since there were no objections in Gurkirpal's mail
above we went this way.</div>
<div><br>
</div>
<div>Now if I look into state_trackers/omx_tizonia, in fact
the common code with state_trackers/omx_bellagio does not
have anything to do with omx. For example "slice_header".
Maybe it can be moved to gallium/auxiliary/vl/ like it is
done already for vl_rbsp_init. Same for omx_get_screen.</div>
</div>
</div>
</blockquote>
<br>
Yeah, completely agree.<br>
<br>
<blockquote type="cite"
cite="mid:CAHWPjbU3EN3X8vz+zTCZLf1h1OvhtG969Sa_2nAArP6QaZNamg@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
</div>
<div>So I suggest this 'factorization' to be not a blocker for
merging state_trackers/omx_tizonia into usptream. But later
on we can move gradually bits from
state_trackers/omx_bellagio to gallium/auxiliary. And then
make state_trackers/omx_tizonia use it as well.</div>
</div>
</div>
</blockquote>
<br>
I would really prefer the other way around, e.g. re-factor first and
then merge. <br>
<br>
<blockquote type="cite"
cite="mid:CAHWPjbU3EN3X8vz+zTCZLf1h1OvhtG969Sa_2nAArP6QaZNamg@mail.gmail.com">
<div dir="ltr">
<div>
<div>This way you will only bother about maintaining
state_trackers/omx_bellagio the time being. This also allows
to not slowly get its work lost.</div>
<div><br>
</div>
<div>Of course we would have done differently if we knew
advance. But as today Gurkirpal won't have enough time to do
this factorization/move as the project ends in 1 week.
Having all of this merged in upstream is not mandatory to
succeed the project but Gurkirpal will need some rest after
these 3 months of hard work. And who knows what happens
after, whether he will still be around after sometimes or
not. And this is entirely up to him.</div>
<div><br>
</div>
<div>So again I suggest this factorization/move not to be a
blocker for the reasons above. What do you think?</div>
</div>
</div>
</blockquote>
<br>
As I wrote above I would rather prefer that this deduplication
happens before the merge, but that Gurkirpal doesn't have much more
time for working on that is a good argument against it.<br>
<br>
BTW: What is Gurkirpal doing after his GSoC project?<br>
<br>
Regards,<br>
Christian.<br>
<br>
<blockquote type="cite"
cite="mid:CAHWPjbU3EN3X8vz+zTCZLf1h1OvhtG969Sa_2nAArP6QaZNamg@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Thx</div>
<div>Julien</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>