<meta http-equiv="Content-Type" content="text/html; charset=utf-8">I guess it's not clear to me what the difference is between a package that depends on yt and an "affiliated" package.<div><br></div><div>The nice part about analysis modules being in yt proper is that it helps prevent breakage in the module due to changes in yt (although ideally breaking changes in yt aren't supposed to happen) and hopefully also improves testing in the analysis modules, since they can rely on our testing infrastructure.</div><div><br></div><div>That said, if dealing with the yt patch process is too onerous, maybe it would be a good idea to have better support on our website or the docs regarding externally maintained packages that depend on yt.<span></span></div><div><br>On Wednesday, December 30, 2015, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The benefits of an "affiliated package" system (although I agree, that<br>
process is a bit complicated) is that things can be versioned<br>
externally, externally published, etc, and we can slim down some<br>
domain-specificity in the core package. The big downside I think<br>
would be reducing discoverability, and not bundling would make it<br>
harder to encourage folks to use the other packages. That can be<br>
mitigated the way astropy does, with things coming into their repo,<br>
being listed on their projects page, etc. What do people think about<br>
that?<br>
<br>
On Wed, Dec 30, 2015 at 4:39 PM, John ZuHone <<a href="javascript:;" onclick="_e(event, 'cvml', 'jzuhone@gmail.com')">jzuhone@gmail.com</a>> wrote:<br>
> It seems to me that something probably ought to be done, because most of the<br>
> analysis modules are so domain-specific that they often require expertise in<br>
> that particular area in order to give a proper review beyond just code<br>
> errors and/or style. This is often what happens, in PR hangouts I often hear<br>
> “well, the code itself looks good, even though I have no idea what it does."<br>
><br>
> photon_simulator is an example of this (albeit an extreme one). I’ve<br>
> contemplated spinning it off into a separate package, given that its size<br>
> and complexity are both getting rather large, but given that we have more<br>
> than a handful of users for it I feel that this would be too disruptive.<br>
><br>
> As an example of how to do “affiliated packages”, AstroPy has such a notion,<br>
> but I always found the process by which a package achieves this status<br>
> rather complicated.<br>
><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astropy.org_affiliated_&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=16QStc0y5TVdSbSw3ycYEAb9fjLqcgONCaqBNDU3B7k&e=" target="_blank">http://www.astropy.org/affiliated/</a><br>
><br>
> On Dec 30, 2015, at 5:25 PM, Matthew Turk <<a href="javascript:;" onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> This is an interesting discussion ... and to be honest, I'm kind of<br>
> left wondering if maybe we should be encouraging more analysis modules<br>
> to be external packages. I came into this thinking that we would want<br>
> to make analysis modules behave more like external packages that get<br>
> bundled, but I'm not sure that's the case after all. Unfortunately,<br>
> we don't *have* a method for defining "affiliated" packages, and we<br>
> certainly don't have (or *want*) an update mechanism for external<br>
> packages that build on yt. But this becomes something of a<br>
> self-reinforcing loop ... Maybe we should come up with something like<br>
> that, so that projects that build on yt can be "advertised" somehow in<br>
> the base package, or something. I am not sure.<br>
><br>
> Anyway, the responses to this thread make me think perhaps we<br>
> shouldn't lower the review barrier after all -- going from 3 to 2 is<br>
> perhaps just window dressing, and maybe we should encourage the<br>
> analysis modules to have higher bus factors.<br>
><br>
> -Matt<br>
><br>
> On Tue, Dec 29, 2015 at 5:09 PM, Nathan Goldbaum <<a href="javascript:;" onclick="_e(event, 'cvml', 'nathan12343@gmail.com')">nathan12343@gmail.com</a>><br>
> wrote:<br>
><br>
> I agree. If we can identify maintainers for analysis modules, I think only<br>
> one additional approval besides the maintainer is fine. If the maintainer<br>
> proposes the PR, they should try to get at least one person to look over it<br>
> in detail before it gets merged.<br>
><br>
> On Tuesday, December 29, 2015, Britton Smith <<a href="javascript:;" onclick="_e(event, 'cvml', 'brittonsmith@gmail.com')">brittonsmith@gmail.com</a>> wrote:<br>
><br>
><br>
> I agree that the number of approvals is less important than ensuring that<br>
> PRs come with appropriate tests and docs. If the PR is a change to an<br>
> existing analysis module, we should just make sure the relevant devs are<br>
> identified and that they sign off on it. If it's something brand new, I<br>
> think 2 or 3 people is probably still a good idea.<br>
><br>
> On Tue, Dec 29, 2015 at 4:44 PM, Matthew Turk <<a href="javascript:;" onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>><br>
> wrote:<br>
><br>
><br>
> Ideally, with the barrier to acceptance reduced, the reviews that come<br>
> in may be deeper and more thoughtful ... and less along the lines of<br>
> "Can somebody just hit the approve button?"<br>
><br>
> On Tue, Dec 29, 2015 at 4:41 PM, John ZuHone <<a href="javascript:;" onclick="_e(event, 'cvml', 'jzuhone@gmail.com')">jzuhone@gmail.com</a>> wrote:<br>
><br>
> +1 for lowering the barrier. At a minimum, tests should pass, and new<br>
> tests<br>
> should be encouraged if possible. Docs as well.<br>
><br>
> Not too worried about 1 or 2 approvals. We could try 2 at first to see<br>
> if<br>
> this helps things out.<br>
><br>
> On Dec 29, 2015, at 5:39 PM, Cameron Hummels <<a href="javascript:;" onclick="_e(event, 'cvml', 'chummels@gmail.com')">chummels@gmail.com</a>><br>
> wrote:<br>
><br>
> As long as the code being changed is local to an analysis module and<br>
> not<br>
> used by other parts of the main yt codebase, yes, I'm all for dropping<br>
> the 3<br>
> reviewer requirement to 2. 1 might be pushing it though.<br>
><br>
> On Tue, Dec 29, 2015 at 2:38 PM, Matthew Turk <<a href="javascript:;" onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>><br>
> wrote:<br>
><br>
><br>
> That's precisely what I had in mind.<br>
><br>
> On Tue, Dec 29, 2015 at 4:36 PM, Nathan Goldbaum<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'nathan12343@gmail.com')">nathan12343@gmail.com</a>><br>
> wrote:<br>
><br>
> On Tue, Dec 29, 2015 at 4:29 PM, Matthew Turk<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>><br>
> wrote:<br>
><br>
><br>
> [+-][01] on reducing review overhead for analysis modules?<br>
><br>
><br>
><br>
> Does this just mean reducing the number of PR reviewers before we<br>
> merge<br>
> pull<br>
> requests? I'd be ok with that, but just want to clarify what you<br>
> have in<br>
> mind.<br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Cameron Hummels<br>
> NSF Postdoctoral Fellow<br>
> Department of Astronomy<br>
> California Institute of Technology<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__chummels.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=TV-5VODrs2RGPQF5JmEo-ecEvpMqK_ToakFWDl67iT8&e=" target="_blank">http://chummels.org</a><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.spacepope.org_listinfo.cgi_yt-2Ddev-2Dspacepope.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=hgcBC3x6dKFoTrmFmMYYbKNfiHZlGLKliIidd1LwmHI&m=4akita9aTID5rzGeDi6qZw5I9emXgjn7L-qZvt6gpHI&s=wNMJr53lrcT71OnW4wuFdzw-SazoMiPcP8h4CFouIC8&e=" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div>