<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 December 2015 at 04:35, Sandro Mathys <span dir="ltr"><<a href="mailto:sandro@midokura.com" target="_blank">sandro@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro <<a href="mailto:galo@midokura.com">galo@midokura.com</a>> wrote:<br>
> Hi,<br>
><br>
>> I think the goal of this split is well explained by Sandro in the first<br>
>> mails of the chain:<br>
>><br>
>> 1. Downstream packaging<br>
>> 2. Tagging the delivery properly as a library<br>
>> 3. Adding as a project on pypi<br>
><br>
> Not really, because (1) and (2) are *a consequence* of the repo split. Not a<br>
> cause. Please correct me if I'm reading wrong but he's saying:<br>
><br>
> - I want tarballs<br>
> - To produce tarballs, I want a separate repo, and separate repos have (1),<br>
> (2) as requirements.<br>
<br>
</span>No, they're all goals, no consequences. Sorry, I didn't notice it<br>
could be interpreted differently<br></blockquote><div><br></div><div>I beg to disagree. The location of code is not a goal in itself. Producing artifacts such as tarballs is.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> This looks more accurate: you're actually not asking for a tarball. You're<br>
> asking for being compatible with a system that produces tarballs off a repo.<br>
> This is very different :)<br>
><br>
> So questions: we have a standalone mirror of the repo, that could be used<br>
> for this purpose. Say we move the mirror to OSt infra, would things work?<br>
<br>
</span>Good point. Actually, no. The mirror can't go into OSt infra as they<br>
don't allow direct pushes to repos - they need to go through reviews.<br>
Of course, we could still have a mirror on GitHub in midonet/ but that<br>
might cause us a lot of trouble.<br></blockquote><div><br></div><div>I don't follow. Where a repo is hosted is orthogonal to how commits are added. If commits to the mirror must go via gerrit, this is perfectly doable.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">> But create a lot of other problems in development. With a very important<br>
> difference: the pain created by the mirror solution is solved cheaply with<br>
> software (e.g.: as you know, with a script). OTOH, the pain created by<br>
> splitting the repo is paid in very costly human resources.<br>
<br>
</span>Adding the PMC as a submodule should reduce this costs significantly,<br>
no? Of course, when working on the PMC, sometimes (or often, even)<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
there will be the need for two instead of one review requests but the<br>
content and discussion of those should be nearly identical, so the<br>
actual overhead is fairly small. Figure I'm missing a few things here<br>
- what other pains would this add?<br></blockquote><div><br>No, it doesn't make things easier. We already tried.<br><br>Guillermo explained a few reasons already in his email.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> I do get this point and it's a major concern, IMO we should split to a<br>
> different conversation as it's not related to where PYC lives, but to a more<br>
> general question: do we really need a repo per package?<br>
<br>
</span>No, we don't. Not per package as you outlined them earlier: agent, cluster, etc.<br>
<br>
Like Jaume, I know the RPM side much better than the DEB side. So for<br>
RPM, one source package (srpm) can create several binary packages<br>
(rpm). Therfore, one repo/tarball (there's an expected 1:1 relation<br>
between these two) can be used for several packages.<br>
<br>
But there's different policies for services and clients, e.g. the<br>
services are only packaged for servers but the clients both for<br>
servers and workstations. Therefore, they are kept in separate srpms.<br>
<br>
Additionally, it's much easier to maintain java and python code in<br>
separate srpms/rpms - mostly due to (build) dependencies.<br></blockquote><div><br></div><div>What's your rationale for saying this? Could you point at specific maintenance points that are made easier by having different languages in separate repos? <br> <br></div><div>g</div></div></div></div>