Re: [Release-team] Status of initial tech doc testing
Ahh, I see. The purpose of release notes is to document updates since the last release. Since there hasn't been any changes in the code, there are no updates, so we don't need to worry about the lack of release nodes. The lack of a full test is somewhat problematic. Modules that weren't tested may have been dependent on change made in other, updated modules. I expect once we have some automated testing system in place, we will be able to easily do this. Until then opportunistically rerunning tests on modules that aren't in scope for a build seems like a good idea. ----- Original Message -----
From: "Nomi Harris" <[email protected]> To: "Dan Olson" <[email protected]> Cc: [email protected] Sent: Monday, August 12, 2013 1:05:16 AM Subject: Re: [Release-team] Status of initial tech doc testing
On Aug 11, 2013, at 10:53 PM, Dan Olson <[email protected]> wrote:
I'm not sure I understand.. Are you saying the dmg itself is a service?
No, that's not what I meant.
We're going to release everything that was tagged and tested this time around, along with anything that has ever been tested and released. However the modules that were not tested during this build will be released as the last tagged version.
Right...but some modules didn't have release notes last time and aren't "in" this release--so we didn't check for release notes--yet they are still being released in the dmg/IRIS (as the last tagged version), having managed to avoid being called on the release notes requirement. An example of this would be feature_selection (or is that not in the dmg or IRIS?)
Not a big deal, just something to clean up at some point. I don't think there are many modules that fall into that category.
Nomi
----- Original Message -----
From: "Nomi Harris" <[email protected]> To: [email protected] Sent: Monday, August 12, 2013 12:47:02 AM Subject: Re: [Release-team] Status of initial tech doc testing
It occurred to me, if we're creating a new dmg and new IRIS, then we're releasing services that weren't "in" this release, aren't we? So they weren't tested or checked for API docs or release notes, but they get released anyway? Am I missing something here about what it means to be "in" a release?
Update on API docs (for services "in" this release):
On Aug 9, 2013, at 9:55 AM, Nomi Harris < [email protected] > wrote:
Thanks. expression still has an extra webroot that needs to be removed. Now fixed
Most of the modules now have API docs in the right place. The only exceptions: functional_ortholog_predictor (no dir in http://140.221.84.191/services/docs/ ) (is fine, I just looked in the wrong place the first time)
assembly: No obvious API doc in http://140.221.84.191/services/docs/assembly/ seems to have CLI documentation but not API
matR: has dir but no API doc Still no API doc
shock_service: there is a "shock_store" (empty) directory in http://140.221.84.191/services/docs/ but no shock dir. Maybe a Makefile problem? This is still the case
typecomp: Has there been a decision that it doesn't need API docs since it's for internal use? Seems like it would still be useful to have API docs for the use of internal people. I agree with this. :-)
As for the release notes, almost all the developers have now created or updated them, so yay! The only two services that are "in" this release and not just internal or dependencies, that lack up-to-date release notes, are: KBaseFBAModeling [but I kind of feel sorry for that module--it had a hard day today, what with unexpectedly having its lib and docs dirs removed] Workspace service
Nomi
On Aug 8, 2013, at 9:31 AM, Shane Canon < [email protected] > wrote:
I fixed auth and expression.
--S
On Aug 8, 2013, at 9:22 AM, Nomi Harris < [email protected] > wrote:
On Aug 7, 2013, at 7:58 PM, Michael Sneddon < [email protected] > wrote:
Nearly all of the services that have been deployed passed the initial doc testing.
The two exceptions are 'sim_service', which is not deploying API docs at all (needs to add the proper doc generation and deployment code to its Makefile), and 'search', which was deployed to a test VM that I couldn't find (not available from t1 by ssh search ??), and has no docs appearing here: http://140.221.84.191/services/docs/search/
Bob fixed the Makefile and the API doc should appear when sim_service is redeployed.
In addition, several modules do have proper documentation that seems to be properly deployed, but is not appearing here: http://140.221.84.191/services/docs . It's probably just a proxy issue, but here is the list of those modules:
auth_service The doc now appears where it should but there is an extra self-referential webroot link in http://140.221.84.191/services/docs/authorization_server/ so that you can go to, for example, http://140.221.84.191/services/docs/authorization_server/webroot/webroot/web...
cluster_service Now ok
expression Almost: the doc is at http://140.221.84.191/services/docs/expression/webroot/ExpressionServices.ht... rather than http://140.221.84.191/services/docs/expression/ExpressionServices.html as it should.
KBaseFBAModeling Now ok, at http://140.221.84.191/services/docs/fbaModelServices/fbaModelServices.html
plant_expression_service Now ok at http://140.221.84.191/services/docs/PlantExpressionService/PlantExpressionSe...
_______________________________________________ Release-team mailing list [email protected] https://lists.kbase.us/mailman/listinfo/release-team
_______________________________________________ Release-team mailing list [email protected] https://lists.kbase.us/mailman/listinfo/release-team
participants (1)
-
Dan Olson