<div dir="ltr"><div><div>Pablo, Chris, and George,<br><br></div>I&#39;m glad to know that there are other similar ongoing efforts &amp; this may grow into a joint project. (I agree that many commonly-used methods are better refactored back into API.)<br><br></div><div>Thanks for the ideas and support. It would be great if some of you could set up a broadly themed, developer-enticing repo (&quot;bputils&quot;, &quot;bioutils&quot;, &quot;user-supplied utilities&quot;, &quot;workflow tools&quot;, ?) and wiki page under bioperl so we could proceed to fill the content.<br></div><div><br></div><div>Thanks &amp; best,</div><div><br></div><div>weigang</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 14, 2014 at 2:30 PM, Fields, Christopher J <span dir="ltr">&lt;<a href="mailto:cjfields@illinois.edu" target="_blank">cjfields@illinois.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div>It’s ‘approved&#39; :)</div>
<div><br>
</div>
<div>Easy enough to set up a repo within the bioperl space for this and grant permissions to whomever (just need a github account).  We just need a name for the repo.  </div>
<div><br>
</div>
<div>We can also set up a wiki presence on <a href="http://bioperl.org" target="_blank">http://bioperl.org</a>, but we’ve been discussing (off-list) using the GitHub wiki (or readthedocs) and setting up a GitHub Pages portal for projects:</div>
<div><br>
</div>
<div><a href="https://help.github.com/articles/user-organization-and-project-pages/" target="_blank">https://help.github.com/articles/user-organization-and-project-pages/</a> </div>
<div><br>
</div>
<div>This might may be a good place to start such an initiative.</div>
<div><br>
</div>
<div>chris</div><div><div>
<br>
<div>
<div>On Dec 13, 2014, at 11:48 PM, Weigang Qiu &lt;<a href="mailto:weigangq@gmail.com" target="_blank">weigangq@gmail.com</a>&gt; wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Hi, George, Chris, and Cacau: <br>
</div>
<div><br>
That&#39;s my question as well: these are bp wrappers and utility scripts, not APIs that fits into CPAN naturally. I have an informal source-forge repository for bp-utils, but not quite ready for form formal release.<br>
<br>
My intention of having it somehow housed within bioperl is not only for exposure and attracting usage and development, but also to pay proper tribute to you guys&#39; hard work maintaining and developing bioperl.<br>
<br>
</div>
<div>I appreciate the suggestion of having its own name space. If approved, I (and my lab members) will make sure it doesn&#39;t not fall into poor maintenance and being an orphan. Having a wiki presence may be a good first step to gradually and properly roll it
 out?<br>
<br>
</div>
<div>thanks,<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Dec 13, 2014 at 11:12 PM, Fields, Christopher J <span dir="ltr">
&lt;<a href="mailto:cjfields@illinois.edu" target="_blank">cjfields@illinois.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On Dec 13, 2014, at 3:11 PM, George Hartzell &lt;<a href="mailto:hartzell@alerce.com" target="_blank">hartzell@alerce.com</a>&gt; wrote:<br>
<br>
&gt; Fields, Christopher J writes:<br>
&gt;&gt; Hi Weigang,<br>
&gt;&gt;<br>
&gt;&gt; I wonder whether it would be better to have a separate bputils repo<br>
&gt;&gt; in the BioPerl space.  This would allow development to continue w/o<br>
&gt;&gt; tying it directly to a release, and I think would solve the<br>
&gt;&gt; exposure problem much more so than having it included in the main<br>
&gt;&gt; bioperl-live repo.  We could also feasibly include it as part of<br>
&gt;&gt; the main CPAN bioperl release, maybe by simply linking to it as a<br>
&gt;&gt; git submodule and packaging it up.<br>
&gt;&gt; [...]<br>
&gt;<br>
&gt; Given how hard you&#39;ve been working to break things out of the core and<br>
&gt; keep orphan things that *are* in core working, I&#39;d suggest that there<br>
&gt; would have to be a really pressing technical reason (and longterm<br>
&gt; support commitment) to include the the main CPAN release.<br>
&gt;<br>
&gt; Seems *way* cleaner to wrap it up into it&#39;s own CPAN release, give it<br>
&gt; a good, evocative name, and make sure the distribution is well built<br>
&gt; (correct meta info, dependencies, etc...).<br>
&gt;<br>
&gt; Then it&#39;ll be easy to find, easy to install and will not increase the<br>
&gt; support burden of the core (or complicate the ongoing cleanup).<br>
&gt;<br>
&gt; Errr, wait.  Someone *did* ask what I thought, didn&#39;t they? :)<br>
&gt;<br>
&gt; g.<br>
<br>
</div>
</div>
Yes to all of this :)<br>
<br>
My only question would be, are there a lot of distributions that consist primarily of scripts that rely completely on another distribution?<br>
<br>
chris</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>Weigang Qiu (邱伟刚)<br>
117-14 Union Turnpike<br>
AC3<br>
Kew Gardens, New York 11415<br>
<a href="tel:1-917-678-3301" value="+19176783301" target="_blank">1-917-678-3301</a></div>
</div>
</blockquote>
</div>
<br>
</div></div></div>

</blockquote></div><br><br clear="all"><br>-- <br><div>Weigang Qiu (邱伟刚)<br>117-14 Union Turnpike<br>AC3<br>Kew Gardens, New York 11415<br><a href="tel:1-917-678-3301" value="+19176783301" target="_blank">1-917-678-3301</a></div>
</div></div>