[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[
https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1149#comment-1149
]
Cassandra Targett commented on SOLR-12930:
--
Sorry for the length of the comment, there are a few things I wanted to make
sure were clear, both in what I have been suggesting and what I know about the
realities of trying to publish some docs-something, no matter how casually we
try to do it.
{quote}I think the reference guide needs to be for end users and not include
things being discussed here...
{quote}
I agree, it should not be part of the standard Ref Guide. Also there are
release rules about VOTES to publish the Ref Guide (since it is an "official"
artifact of the project) that would be obstructions if we applied them to
developer documentation. A goal needs to be to remove as many obstructions as
possible - or at least not put them up at the start.
A sibling dev guide is exactly the proposal I made in my earlier comments and
in the example project I created.
The basic infrastructure I created in my small example project is mostly only
there if we want to publish an HTML version of a Dev Guide online, and not only
rely on developers to either load pages in their IDEs (which most committers
could be expected to do as a general rule) or have to go find the pages
somewhere in the tree in Github to look at them (which new contributors may not
know to do). A one-stop place for "everything anyone needs to know about
developing Solr", linked from the Resources page of the website, would be quite
helpful IMO to new potential contributors.
I think they _should_ be in asciidoc format, so all our docs are in the same
file format; it reduces context switching which would encourage participation
from everyone.
I have not been suggesting that we copy everything we do today for the Ref
Guide and do it for developer docs (or, I was attempting to specifically not
suggest that). If you look at the strawman project I made, it's not nearly as
complex as the Ref Guide. That comparison requires you to have a sense for how
the Ref Guide works, but it's basically just an ant target that downloads a
.jar and builds an HTML page in about 3 seconds. It's a lot simpler than the
Ref Guide process which includes a lot of page templates and nav building and
validation for correctness that we could forego for this case.
{quote}I don't think we necessarily need to have it all on one page, there
probably shouldn't be very many total pages...
{quote}
Regarding this point - just to make sure we're referring to the same thing, my
point about a single page was not that all the content lives in some single
huge file. That would be a pain to maintain and edit. The content should be in
multiple files that each discuss a specific area of development (setting up
your IDE, how to build, how to write tests, how to submit patches, etc.). The
idea of a single file was about taking all those smaller files we write and
_publishing_ them as a single HTML page that is the thing make public. This is
is done very easily with Asciidoctor
([https://asciidoctor.org/docs/user-manual/#include-directive]).
But, in case you meant having multiple HTML pages as the output - as soon as
you have more than one page, you need navigation between those pages. You don't
get navigation between pages without some work on our part to make it happen
(perhaps a page hierarchy, then you need clues for the user about where they
are in the hierarchy) and some of the complexity of the Ref Guide today is in
building the page navigation and you can only do that if you have a template
for the page so they are all the same...essentially the only way to get that is
to do something like Jekyll, which is why we have to use that today for the Ref
Guide. A single HTML page allows us to forget all of those concerns because the
nav - such as it is - is built into the side of the page during the build
process. We only need to make sure all the pages are included in the mono-page
using the include directive functionality I mentioned ^^.
{quote}At some point in the relatively near future, all git repositories at
Apache will be migrated from the git-wip system to gitbox
{quote}
The Gitbox transition is interesting in this context. One of the things this
change will do is make the Github repo the primary repository, which for us
today is a mirror of the ASF Git repo (our current ASF Git repo becomes the
read-only mirror). So instead of pushing our commits to ASF Git, we push them
to Github, and we pull new changes from Github. That opens up all of Github's
features which today we cannot use (a primary one being the ability to interact
with pull requests directly from Github).
For this discussion an interesting feature then would be the ability to use
Github Pages ([https://pages.github.com/]), which has deep Asciidoctor
integration and
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665977#comment-16665977 ] Shawn Heisey commented on SOLR-12930: - bq. As for the details of whether it's a section of the standard ref guide or a sibling directory or... I think the reference guide needs to be for end users and not include things being discussed here. I've got no interest in hiding the information from users, but I think it would be out of place in the reference guide and be confusing to novices. So my thought is a sibling dev guide. It certainly wouldn't be as big or as complex as the ref guide, and although I don't think we necessarily need to have it all on one page, there probably shouldn't be very many total pages, at least in the early days. Later, we might decide on some kind of organizational concept which changes that assumption. Something else to think about: Do we want to move the complex moving parts for building the guide so a dev guide could be built that includes things like ReleaseToDo and similar best practices for Lucene? Would we want to have separate dev guides for both halves of the project? bq. Actually, GitHub renders Asciidoc right in the source browse That's really awesome. TL;DR: One of my past conversations with Infra yielded a tidbit which I did mention on dev@l.a.o at one point: At some point in the relatively near future, all git repositories at Apache will be migrated from the git-wip system to gitbox. I don't know the details, but apparently gitbox includes some deep integration with github. I wonder if there might be something interesting to be done with github's asciidoc rendering. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > Attachments: solr-dev-docs.zip > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665831#comment-16665831 ] Erick Erickson commented on SOLR-12930: --- To me, the main value of having the dev docs _somewhere_ in the source tree is pretty much the same argument as having the ref guide: you can (ahem) _encourage_ people to add dev guide stuff _with the patch_. Much more coherent than "I'll get to the cwiki later" ;) As for the details of whether it's a section of the standard ref guide or a sibling directory or... I'm perfectly happy to defer to the opinion of people who actually do the work. Whatever's easiest > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > Attachments: solr-dev-docs.zip > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[
https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665801#comment-16665801
]
Cassandra Targett commented on SOLR-12930:
--
bq, I thought it must be Asciidoc and then publish a current working version to
cwiki
Oh god, no, we dropped cwiki entirely. It's all hosted on the Solr website now.
I did look into pushing Asciidoc content to Confluence, and the main tools out
there are kind of old, or only work with old versions. I don't know that's the
best approach anyway - it's something that could break at any time if one
version changes on either side.
I've come up with a simple example project that uses Asciidoctor with an Ant
target to generate an HTML file, if that's what we want. It's all kind of quick
& dirty - a bunch of stuff would need to be done to fully integrate it with the
project for real - but it shows the basic concepts if you aren't familiar with
"what's the basic Asciidoctor can do" vs. "what did we add to Asciidoctor for
our needs". Just unzip the {{solr-dev-docs.zip}}, run the {{ant build-devdocs}}
target, and then look in the {{build/html}} directory for {{dev-docs.html}}.
Even without generating an HTML we publish, one thing I was thinking is we
could add a new directory at {{lucene-solr/solr/docs}} that includes the
dev-docs content + the ref guide. But I'm not sure I care all that much about
where the dev docs go; it just seemed they were docs and all docs-things could
go together.
> Add great developer documentation for writing tests.
>
>
> Key: SOLR-12930
> URL: https://issues.apache.org/jira/browse/SOLR-12930
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665795#comment-16665795 ] Mark Miller commented on SOLR-12930: Ah, okay, no problem. I'm not super familiar with how the ref guide works - I thought it must be Asciidoc and then publish a current working version to cwiki and you could just dupe that approach. Before assumed that was the case, I was going to mention publishing to cwiki would be cool but probably not necessary. Even if we can't publish to a site at all, it's docs for people really developing for Solr - it would not be the worst to be a local thing. Sounds like GitHub will offer something very lower barrier for online, so that sounds promising. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665666#comment-16665666 ] Alexandre Rafalovitch commented on SOLR-12930: -- Actually, GitHub renders Asciidoc right in the source browse, e.g.: [https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/about-filters.adoc] It is not perfect (e.g. not resolving the imports) and does not help with built-output, but it may be ok as a public preview. There is also an option of using something like [Netlify|https://www.netlify.com/] which does support Jekyll and allows to build from a repo, but it needs to be setup/configured right. A separate project. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665659#comment-16665659 ] Cassandra Targett commented on SOLR-12930: -- I think we'd have to pick either use cwiki or use the slimmed-down Ref Guide (Asciidoctor) way. I'm not coming up with a way to have both (keep source with code & also publish to cwiki) off the top of my head, but I'll do a little bit of research to see what's out there. Maybe we can - we'd still have to have some kind of "publish" process, though. The benefit of cwiki is instant publication as soon as you hit enter to save the page, but the con is your docs are in some other repo separate from the code it's trying to help you use. It's pretty much the exact opposite pro/con for the Asciidoctor way - your docs are in the same repo as your code, but you have to have a publication process of some kind to get it into a browser-readable form like HTML. I'll come up with a strawman of sorts for publication process so people get a feel for what that would be like so we can try to get this together quickly. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665533#comment-16665533 ] Mark Miller commented on SOLR-12930: Actually it sounds great to me. It really does seem like the best idea is the same thing as the ref guide, but more relaxed, no releases. So we would just set it up like the current working version of the ref guide, simplified as Cassandra suggests? And still would want a new cwiki space to publish to? If anyone has time to help get that going, I will definitely start adding some content any time. If we need the new cwiki space, I can herd that cat. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665282#comment-16665282 ] Mark Miller commented on SOLR-12930: bq. docs stay there right next to the code That sounds good to me. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
+1, also from the perspective that I could continue to forget the Wiki markup, it's been falling out of my brain the more I work with asciidoc. Would this become part of the regular source checkout, maybe in a sibling directory to solr-ref-guide or separate? Erick On Fri, Oct 26, 2018 at 6:56 AM Cassandra Targett (JIRA) wrote: > > > [ > https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665207#comment-16665207 > ] > > Cassandra Targett commented on SOLR-12930: > -- > > bq. Or we could aim for a new asciidoctor powered solr-developerguide in > git... > > Oh my god, how is it I didn't think of that? > > Seriously, though, this is an idea worth exploring - we already have docs on > "how to write the Ref Guide" in asciidoc, and we can make a new area of our > website to host it. If we don't try to put it in the Ref Guide or need to > publish a PDF as the "official" doc, some of the strictness we have for the > Ref Guide can be relaxed to make it easier. > > My personal recommendation would be to write the content into separate files, > but publish it in a single page format, similar to how HBase does it: > https://hbase.apache.org/book.html#developer (they mix user docs & dev docs > together, so ignore that part - what I mean is we could present it similarly > as a single page, but with just dev doc content on a single page with a TOC > on the left or right side). Doing that is incredibly simple with OOB > Asciidoctor - we wouldn't even need Jekyll in this case - and it would be > easy to set up a simple Ant target for it. > > > > Add great developer documentation for writing tests. > > > > > > Key: SOLR-12930 > > URL: https://issues.apache.org/jira/browse/SOLR-12930 > > Project: Solr > > Issue Type: Sub-task > > Security Level: Public(Default Security Level. Issues are Public) > > Components: Tests > >Reporter: Mark Miller > >Priority: Major > > > > > > > -- > This message was sent by Atlassian JIRA > (v7.6.3#76005) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665207#comment-16665207 ] Cassandra Targett commented on SOLR-12930: -- bq. Or we could aim for a new asciidoctor powered solr-developerguide in git... Oh my god, how is it I didn't think of that? Seriously, though, this is an idea worth exploring - we already have docs on "how to write the Ref Guide" in asciidoc, and we can make a new area of our website to host it. If we don't try to put it in the Ref Guide or need to publish a PDF as the "official" doc, some of the strictness we have for the Ref Guide can be relaxed to make it easier. My personal recommendation would be to write the content into separate files, but publish it in a single page format, similar to how HBase does it: https://hbase.apache.org/book.html#developer (they mix user docs & dev docs together, so ignore that part - what I mean is we could present it similarly as a single page, but with just dev doc content on a single page with a TOC on the left or right side). Doing that is incredibly simple with OOB Asciidoctor - we wouldn't even need Jekyll in this case - and it would be easy to set up a simple Ant target for it. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665177#comment-16665177 ] Alexandre Rafalovitch commented on SOLR-12930: -- +1 on the idea of asciidoc, especially since it allows to embed code segments straight from source, like in SolrJ example. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[
https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665127#comment-16665127
]
Jan Høydahl commented on SOLR-12930:
Or we could aim for a new asciidoctor powered {{solr-developerguide}} in git,
which over time could grow with topics like "How to write a good patch", "How
to work with Git", "How to develop av Solr plugin" The benefit of asciidoc
is that everybody already use it for ref guide, and we have processes in place
to push it as PDF or as part of the webpage. And of course, it is versioned, so
if there is a big change for developers in a certain version the docs stay
there right next to the code :)
> Add great developer documentation for writing tests.
>
>
> Key: SOLR-12930
> URL: https://issues.apache.org/jira/browse/SOLR-12930
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665110#comment-16665110 ] Cassandra Targett commented on SOLR-12930: -- [~markrmil...@gmail.com], I think it used to be that someone just filed an issue with INFRA with the request, but I looked it up and found this which is recently updated, so I assume it's the current approach: https://cwiki.apache.org/confluence/display/INFRA/Cwiki#Cwiki-HowdowerequestaCWIKISpace?. Apparently there is now a self-serve portal where a space can be requested: https://selfserve.apache.org/, but it looks like our PMC chair ([~jpountz]) needs to be the one who makes the request. The space ID "solr" is still taken by the old Ref Guide - we have an automatic redirect in place for anyone who goes to the old Ref Guide URLs. I think we still want that, but maybe another ID like "solr-dev" is OK? > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664323#comment-16664323 ] Mark Miller commented on SOLR-12930: [~ctargett], [~hossman] - either of you know how to or have the power to get us a Solr Developer space in the cwiki? > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664319#comment-16664319 ] Anshum Gupta commented on SOLR-12930: - That sounds reasonable (y) > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664315#comment-16664315 ] Mark Miller commented on SOLR-12930: Yeah, the bulk of the good stuff will probably come down the road, but we could use really even just the basics for what we have now. When it's time to write a Solr or SolrCloud test as a new dev, it's really quite challenging to understand anything or get started. You just find something and copy and push off in some direction. Even know, those that know how to right good tests, what style of SolrCloud test to write, that you have to beast tests, how to beast them etc. What a unit and integration tests is, why we need both, how to write both etc (it's going to get easier, but you can still do some of this today) So a lot to do later, but a ton we could do now. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664306#comment-16664306 ] Anshum Gupta commented on SOLR-12930: - [~markrmil...@gmail.com] - we'd do this once we've done or decided on how/what to do with most of the other stuff, right? i.e. decided and split the unit/integration tests, fix the framework etc. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
