<div dir="ltr"><div><div>Pablo, Chris, and George,<br><br></div>I'm glad to know that there are other similar ongoing efforts & 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 ("bputils", "bioutils", "user-supplied utilities", "workflow tools", ?) and wiki page under bioperl so we could proceed to fill the content.<br></div><div><br></div><div>Thanks & 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"><<a href="mailto:cjfields@illinois.edu" target="_blank">cjfields@illinois.edu</a>></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' :)</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 <<a href="mailto:weigangq@gmail.com" target="_blank">weigangq@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Hi, George, Chris, and Cacau: <br>
</div>
<div><br>
That'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' 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'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">
<<a href="mailto:cjfields@illinois.edu" target="_blank">cjfields@illinois.edu</a>></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 <<a href="mailto:hartzell@alerce.com" target="_blank">hartzell@alerce.com</a>> wrote:<br>
<br>
> Fields, Christopher J writes:<br>
>> Hi Weigang,<br>
>><br>
>> I wonder whether it would be better to have a separate bputils repo<br>
>> in the BioPerl space. This would allow development to continue w/o<br>
>> tying it directly to a release, and I think would solve the<br>
>> exposure problem much more so than having it included in the main<br>
>> bioperl-live repo. We could also feasibly include it as part of<br>
>> the main CPAN bioperl release, maybe by simply linking to it as a<br>
>> git submodule and packaging it up.<br>
>> [...]<br>
><br>
> Given how hard you've been working to break things out of the core and<br>
> keep orphan things that *are* in core working, I'd suggest that there<br>
> would have to be a really pressing technical reason (and longterm<br>
> support commitment) to include the the main CPAN release.<br>
><br>
> Seems *way* cleaner to wrap it up into it's own CPAN release, give it<br>
> a good, evocative name, and make sure the distribution is well built<br>
> (correct meta info, dependencies, etc...).<br>
><br>
> Then it'll be easy to find, easy to install and will not increase the<br>
> support burden of the core (or complicate the ongoing cleanup).<br>
><br>
> Errr, wait. Someone *did* ask what I thought, didn't they? :)<br>
><br>
> 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>