<div dir="ltr">On naming, I have a slight preference toward keeping the pulp_ prefix convention, but that might just be rooted in habit. My general feeling is that the name of a git repo should stand on its own, and the fact that it may be present on github within a particular user or organization's namespace does not displace the value of the name itself being fully descriptive.<div><br></div><div>If I fork pulp/contrib, I end up with mhrivnak/contrib. Yes, the list of my repos will show that is was forked from pulp/contrib, but it still seems weird. I have to go to github to see that. If someone forked it from me, now the original name's context is hard to find.</div><div><br></div><div>Even when I merely clone it, I'd get a local directory named "contrib". Perhaps others already organize their local git clones by organization, but I've always just had a flat directory of stuff that's been cloned from all over, because the repo names are usually fully descriptive.<br></div><div><br></div><div>As an example, check out how many Fedora repos start with the word "fedora": <a href="https://git.fedorahosted.org/cgit/?ofs=300">https://git.fedorahosted.org/cgit/?ofs=300</a></div><div><br></div><div>All of that said, it's not a big deal, and I'm happy to adjust my thinking if a lot of folks think of it differently. How about it?</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 2:40 PM, Sean Myers <span dir="ltr"><<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/20/2016 01:49 PM, Jeremy Cline wrote:<br>
> Hi all,<br>
><br>
> Currently, we have development-related files and packages spread out<br>
> across our Git repositories on GitHub. It would be nice if it was all<br>
> part of one repository for developers. This would include things like:<br>
><br>
>  * The Vagrantfile currently in pulp/pulp<br>
>  * The devel Python packages currently in each repo<br>
>  * Release engineering tooling currently in pulp/pulp<br>
>  * Jenkins jobs definitions currently in pulp/pulp_packaging<br>
>  * Ansible playbooks currently in pulp/pulp and pulp/pulp_packaging<br>
>  * Various tools and scripts living in "playpens"<br>
><br>
> It might also be worth breaking out our Ansible roles into their own<br>
> `ansible` repository. Right now we have _two_ sets of Ansible roles<br>
> (one in pulp/pulp and on in pulp/pulp_packaging).<br>
><br>
> What do you all think?<br>
<br>
</span>Yes. I'm also happy to see the ansible books live in devel since they're primarly<br>
used by vagrant and CI, which would both live in devel, and you can't do either<br>
without one or the ansible playbooks.<br>
<br>
+1 for 'devel' and not 'pulp_devel', I still sometimes think that we have a<br>
'packaging' plugin because of the 'pulp_packaging' repo name.<br>
<br>
<br>_______________________________________________<br>
Pulp-list mailing list<br>
<a href="mailto:Pulp-list@redhat.com">Pulp-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-list</a><br></blockquote></div><br></div>