- Release-team - mailman3.cels.anl.gov

Re: [Release-team] Need API doc updated for workspace
by Nomi Harris 02 Jul '14

02 Jul '14

Thanks, Erik. I discussed this issue (updating the API docs when needed) with Erik. In the longer term, he will look into automating this. In the short term, he just needs to know when a service has been (re)deployed so he can update the API doc for it. He and I couldn’t think of any way he would know this unless Dan tells him, but if there’s some way he could be automatically informed, please let us know! Nomi On Jul 2, 2014, at 12:42 PM, Erik Pearson <eapearson(a)lbl.gov> wrote: > Okay, so I can either build the docs from the workspace_deluxe repo 0.1.6 release or someone can just send me or point me to the location of the build/deployed docs, in either case I’ll take care of incorporating the workspace docs into the docs repo. > > Erik. > > > On Jul 2, 2014, at 12:05 PM, Erik Pearson <eapearson(a)lbl.gov> wrote: > >> On Jul 2, 2014, at 11:46 AM, Nomi Harris <nlharris(a)lbl.gov> wrote: >> >>> Dear Release Team, >>> Gavin informed me that the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ is out of date—it should have been updated when the newer version of the workspace service was deployed to production. >>> >>> What is the current situation with the updating of these API docs—does it require a human to copy them somewhere, or should that happen automatically when a service is deployed to production? >> >> This specific doc needs to appear in the docs repo as workspace_service/workspaceService.html. >> >> There is a magic script which which will separate the navigation and the document body and store them in separate files, which are then included directly into the web page (yes, as includes, so whenever the files change the doc web page just shows the new files.) >> >> There is a manual step for the API doc — I will notice the commit to the docs repo and do the work. Release notes will be automatically updated since they are read straight from the repo. There is also a related “Command Line Help” document located at docs/command_line_prod/Workspace_Service_CommandLineHelp.txt and will be updated on the site automatically (it is shown simply as a plain text page). >> >> We have plans to for a documentation build process including detection of changes to source docs. >> >> Erik. >> >>> >>> Also, please add Erik to the release-team mailing list. He is handling the web-facing part (adding the kbase “style” to the API docs). >>> >>> Thanks, >>> Nomi >>> >>> Begin forwarded message: >>> >>>> From: Christopher Henry <chrisshenry(a)gmail.com> >>>> Subject: Re: workspace docs on website out of date >>>> Date: July 2, 2014 at 11:39:23 AM PDT >>>> To: Nomi Harris <nlharris(a)lbl.gov> >>>> Cc: Gavin A Price <gavinaprice(a)gmail.com> >>>> >>>> Yes! >>>> >>>> On Jul 2, 2014, at 1:36 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: >>>> >>>>> Ok, so you’re saying the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ already should have been updated to 0.1.6? >>>>> >>>>> On Jul 2, 2014, at 11:34 AM, Gavin A Price <gavinaprice(a)gmail.com> wrote: >>>>> >>>>>> production has been running 0.1.6 for months. >>>>>> >>>>>> production is *also* running 0.0.5 but no one should be using that other than Chris for data transfer and job handling purposes. >>>>>> >>>>>> -g >>>>>> >>>>>> On 7/2/2014 11:24 AM, Nomi Harris wrote: >>>>>>> When the production version updates to 0.1.6 then the API doc should get updated during the deploy process. >>>>>>> >>>>>>> On Jun 26, 2014, at 4:45 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>>>> >>>>>>>> It's probably because 0.0.5 is still running in production at the workspace and workspace_service endpoints (I think those are right) because the data transfer is still ongoing and FBA still uses the workspace as a job runner. >>>>>>>> >>>>>>>> 0.1.6 is also running at the ws endpoint, but that's the version everyone should be using at this point. >>>>>>>> >>>>>>>> -g >>>>>>>> >>>>>>>> On 6/26/2014 4:39 PM, Nomi Harris wrote: >>>>>>>>> When a service is (re)deployed into production, its API doc is supposed to get pushed as well. I’m not sure why that didn’t happen in this case. I will investigate. >>>>>>>>> >>>>>>>>> On Jun 26, 2014, at 4:37 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> It's been brought to my attention that we're still on version 0.0.5 of the workspace docs here: http://kbase.us/developer-zone/documentation/workspace-service/ >>>>>>>>>> >>>>>>>>>> Should we update to the 0.1.6 docs, which is currently in production? If so, Nomi, could you explain the process? >>>>>>>>>> >>>>>>>>>> Thanks, Gavin >>>>>>> > > _______________________________________________ > Release-team mailing list > Release-team(a)lists.kbase.us > https://lists.kbase.us/mailman/listinfo/release-team

1 0

Re: [Release-team] Need API doc updated for workspace
by Erik Pearson 02 Jul '14

02 Jul '14

Okay, so I can either build the docs from the workspace_deluxe repo 0.1.6 release or someone can just send me or point me to the location of the build/deployed docs, in either case I’ll take care of incorporating the workspace docs into the docs repo. Erik. On Jul 2, 2014, at 12:05 PM, Erik Pearson <eapearson(a)lbl.gov> wrote: > On Jul 2, 2014, at 11:46 AM, Nomi Harris <nlharris(a)lbl.gov> wrote: > >> Dear Release Team, >> Gavin informed me that the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ is out of date—it should have been updated when the newer version of the workspace service was deployed to production. >> >> What is the current situation with the updating of these API docs—does it require a human to copy them somewhere, or should that happen automatically when a service is deployed to production? > > This specific doc needs to appear in the docs repo as workspace_service/workspaceService.html. > > There is a magic script which which will separate the navigation and the document body and store them in separate files, which are then included directly into the web page (yes, as includes, so whenever the files change the doc web page just shows the new files.) > > There is a manual step for the API doc — I will notice the commit to the docs repo and do the work. Release notes will be automatically updated since they are read straight from the repo. There is also a related “Command Line Help” document located at docs/command_line_prod/Workspace_Service_CommandLineHelp.txt and will be updated on the site automatically (it is shown simply as a plain text page). > > We have plans to for a documentation build process including detection of changes to source docs. > > Erik. > >> >> Also, please add Erik to the release-team mailing list. He is handling the web-facing part (adding the kbase “style” to the API docs). >> >> Thanks, >> Nomi >> >> Begin forwarded message: >> >>> From: Christopher Henry <chrisshenry(a)gmail.com> >>> Subject: Re: workspace docs on website out of date >>> Date: July 2, 2014 at 11:39:23 AM PDT >>> To: Nomi Harris <nlharris(a)lbl.gov> >>> Cc: Gavin A Price <gavinaprice(a)gmail.com> >>> >>> Yes! >>> >>> On Jul 2, 2014, at 1:36 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: >>> >>>> Ok, so you’re saying the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ already should have been updated to 0.1.6? >>>> >>>> On Jul 2, 2014, at 11:34 AM, Gavin A Price <gavinaprice(a)gmail.com> wrote: >>>> >>>>> production has been running 0.1.6 for months. >>>>> >>>>> production is *also* running 0.0.5 but no one should be using that other than Chris for data transfer and job handling purposes. >>>>> >>>>> -g >>>>> >>>>> On 7/2/2014 11:24 AM, Nomi Harris wrote: >>>>>> When the production version updates to 0.1.6 then the API doc should get updated during the deploy process. >>>>>> >>>>>> On Jun 26, 2014, at 4:45 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>>> >>>>>>> It's probably because 0.0.5 is still running in production at the workspace and workspace_service endpoints (I think those are right) because the data transfer is still ongoing and FBA still uses the workspace as a job runner. >>>>>>> >>>>>>> 0.1.6 is also running at the ws endpoint, but that's the version everyone should be using at this point. >>>>>>> >>>>>>> -g >>>>>>> >>>>>>> On 6/26/2014 4:39 PM, Nomi Harris wrote: >>>>>>>> When a service is (re)deployed into production, its API doc is supposed to get pushed as well. I’m not sure why that didn’t happen in this case. I will investigate. >>>>>>>> >>>>>>>> On Jun 26, 2014, at 4:37 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> It's been brought to my attention that we're still on version 0.0.5 of the workspace docs here: http://kbase.us/developer-zone/documentation/workspace-service/ >>>>>>>>> >>>>>>>>> Should we update to the 0.1.6 docs, which is currently in production? If so, Nomi, could you explain the process? >>>>>>>>> >>>>>>>>> Thanks, Gavin >>>>>> >>>> >>> >> >

1 0

Re: [Release-team] Need API doc updated for workspace
by Erik Pearson 02 Jul '14

02 Jul '14

On Jul 2, 2014, at 11:46 AM, Nomi Harris <nlharris(a)lbl.gov> wrote: > Dear Release Team, > Gavin informed me that the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ is out of date—it should have been updated when the newer version of the workspace service was deployed to production. > > What is the current situation with the updating of these API docs—does it require a human to copy them somewhere, or should that happen automatically when a service is deployed to production? This specific doc needs to appear in the docs repo as workspace_service/workspaceService.html. There is a magic script which which will separate the navigation and the document body and store them in separate files, which are then included directly into the web page (yes, as includes, so whenever the files change the doc web page just shows the new files.) There is a manual step for the API doc — I will notice the commit to the docs repo and do the work. Release notes will be automatically updated since they are read straight from the repo. There is also a related “Command Line Help” document located at docs/command_line_prod/Workspace_Service_CommandLineHelp.txt and will be updated on the site automatically (it is shown simply as a plain text page). We have plans to for a documentation build process including detection of changes to source docs. Erik. > > Also, please add Erik to the release-team mailing list. He is handling the web-facing part (adding the kbase “style” to the API docs). > > Thanks, > Nomi > > Begin forwarded message: > >> From: Christopher Henry <chrisshenry(a)gmail.com> >> Subject: Re: workspace docs on website out of date >> Date: July 2, 2014 at 11:39:23 AM PDT >> To: Nomi Harris <nlharris(a)lbl.gov> >> Cc: Gavin A Price <gavinaprice(a)gmail.com> >> >> Yes! >> >> On Jul 2, 2014, at 1:36 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: >> >>> Ok, so you’re saying the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ already should have been updated to 0.1.6? >>> >>> On Jul 2, 2014, at 11:34 AM, Gavin A Price <gavinaprice(a)gmail.com> wrote: >>> >>>> production has been running 0.1.6 for months. >>>> >>>> production is *also* running 0.0.5 but no one should be using that other than Chris for data transfer and job handling purposes. >>>> >>>> -g >>>> >>>> On 7/2/2014 11:24 AM, Nomi Harris wrote: >>>>> When the production version updates to 0.1.6 then the API doc should get updated during the deploy process. >>>>> >>>>> On Jun 26, 2014, at 4:45 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>> >>>>>> It's probably because 0.0.5 is still running in production at the workspace and workspace_service endpoints (I think those are right) because the data transfer is still ongoing and FBA still uses the workspace as a job runner. >>>>>> >>>>>> 0.1.6 is also running at the ws endpoint, but that's the version everyone should be using at this point. >>>>>> >>>>>> -g >>>>>> >>>>>> On 6/26/2014 4:39 PM, Nomi Harris wrote: >>>>>>> When a service is (re)deployed into production, its API doc is supposed to get pushed as well. I’m not sure why that didn’t happen in this case. I will investigate. >>>>>>> >>>>>>> On Jun 26, 2014, at 4:37 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>>>> >>>>>>>> It's been brought to my attention that we're still on version 0.0.5 of the workspace docs here: http://kbase.us/developer-zone/documentation/workspace-service/ >>>>>>>> >>>>>>>> Should we update to the 0.1.6 docs, which is currently in production? If so, Nomi, could you explain the process? >>>>>>>> >>>>>>>> Thanks, Gavin >>>>> >>> >> >

1 0

Need API doc updated for workspace
by Nomi Harris 02 Jul '14

02 Jul '14

Dear Release Team, Gavin informed me that the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ is out of date—it should have been updated when the newer version of the workspace service was deployed to production. What is the current situation with the updating of these API docs—does it require a human to copy them somewhere, or should that happen automatically when a service is deployed to production? Also, please add Erik to the release-team mailing list. He is handling the web-facing part (adding the kbase “style” to the API docs). Thanks, Nomi Begin forwarded message: > From: Christopher Henry <chrisshenry(a)gmail.com> > Subject: Re: workspace docs on website out of date > Date: July 2, 2014 at 11:39:23 AM PDT > To: Nomi Harris <nlharris(a)lbl.gov> > Cc: Gavin A Price <gavinaprice(a)gmail.com> > > Yes! > > On Jul 2, 2014, at 1:36 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: > >> Ok, so you’re saying the API doc at http://kbase.us/developer-zone/documentation/workspace-service/ already should have been updated to 0.1.6? >> >> On Jul 2, 2014, at 11:34 AM, Gavin A Price <gavinaprice(a)gmail.com> wrote: >> >>> production has been running 0.1.6 for months. >>> >>> production is *also* running 0.0.5 but no one should be using that other than Chris for data transfer and job handling purposes. >>> >>> -g >>> >>> On 7/2/2014 11:24 AM, Nomi Harris wrote: >>>> When the production version updates to 0.1.6 then the API doc should get updated during the deploy process. >>>> >>>> On Jun 26, 2014, at 4:45 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>> >>>>> It's probably because 0.0.5 is still running in production at the workspace and workspace_service endpoints (I think those are right) because the data transfer is still ongoing and FBA still uses the workspace as a job runner. >>>>> >>>>> 0.1.6 is also running at the ws endpoint, but that's the version everyone should be using at this point. >>>>> >>>>> -g >>>>> >>>>> On 6/26/2014 4:39 PM, Nomi Harris wrote: >>>>>> When a service is (re)deployed into production, its API doc is supposed to get pushed as well. I’m not sure why that didn’t happen in this case. I will investigate. >>>>>> >>>>>> On Jun 26, 2014, at 4:37 PM, Gavin A Price<gavinaprice(a)gmail.com> wrote: >>>>>> >>>>>>> It's been brought to my attention that we're still on version 0.0.5 of the workspace docs here: http://kbase.us/developer-zone/documentation/workspace-service/ >>>>>>> >>>>>>> Should we update to the 0.1.6 docs, which is currently in production? If so, Nomi, could you explain the process? >>>>>>> >>>>>>> Thanks, Gavin >>>> >> >

1 0

Re: [Release-team] it's time to release a new set of products
by Thomas Brettin 03 Jun '14

03 Jun '14

OK Nomi. Dan, can you make progress on a new ubuntu image this week, and can you send the curated list to Bob. Thanks, Tom On Jun 3, 2014, at 6:42 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: > On May 15, 2014, at 10:33 AM, Thomas Brettin <brettin(a)anl.gov> wrote: > >> On May 13, 2014, at 11:06 PM, Thomas Brettin <brettin(a)anl.gov> wrote: >> >>> Nomi has pointed out, and I think she is correct, that our downloads page needs to be updated before the renewal proposal lands in the hands of the review team. This gives us about 2-3 weeks. >>> >>> We need to decide what is possible.I’d like to schedule a meeting to discuss this on before the end of the week India will get in touch to see what time is best. >>> >>> Thanks, >>> Tom >>> > > It’s now been 2-1/2 weeks. I plan to ask Erik today to take the old disk images off the Downloads page (and move them to the “Older releases” page). When the new images are ready, we can add them to the Downloads page. I think it’s better not to have any images up than to have reviewers downloading extremely old images with client code that presumably won’t work with some of the current services. > > I don’t actually see anything on the Downloads page that is worth having up there now—maybe the “.vmdk Daily Development Snapshot”? Do those work? I clicked on it and it downloaded a huge file, but there’s no date or version info attached to it, so it’s impossible to tell how old the contents are. > > <Screen Shot 2014-06-03 at 9.38.37 AM.png> > > >

1 0

Re: [Release-team] it's time to release a new set of products
by Nomi Harris 03 Jun '14

03 Jun '14

On May 15, 2014, at 10:33 AM, Thomas Brettin <brettin(a)anl.gov> wrote: > On May 13, 2014, at 11:06 PM, Thomas Brettin <brettin(a)anl.gov> wrote: > >> Nomi has pointed out, and I think she is correct, that our downloads page needs to be updated before the renewal proposal lands in the hands of the review team. This gives us about 2-3 weeks. >> >> We need to decide what is possible.I’d like to schedule a meeting to discuss this on before the end of the week India will get in touch to see what time is best. >> >> Thanks, >> Tom >> It’s now been 2-1/2 weeks. I plan to ask Erik today to take the old disk images off the Downloads page (and move them to the “Older releases” page). When the new images are ready, we can add them to the Downloads page. I think it’s better not to have any images up than to have reviewers downloading extremely old images with client code that presumably won’t work with some of the current services. I don’t actually see anything on the Downloads page that is worth having up there now—maybe the “.vmdk Daily Development Snapshot”? Do those work? I clicked on it and it downloaded a huge file, but there’s no date or version info attached to it, so it’s impossible to tell how old the contents are.

1 0

Re: [Release-team] Release priorities
by Thomas Brettin 16 May '14

16 May '14

Ahh, just got internet. OK, so for the github stuff I’ve been moving items from git.kbase.us to github once there is a License file in the git.kbase.us based repo. I’ve put a license in some repos for ANL folks, per Rick’s approval, however, those repos that are predominately LBL should have a license placed in them by a LBL person. Shane, I think you would be the best person to do this, but that’s up to you guys. When I create a repo at github, say assembly, i also create an assembly_team. I give that team administrative access to that repo. I put into that team the repo owner and anyone he requests. So for assembly, the assembly_team is fang fang as the owner. The team owner can then add everyone (the kbase group) or can just accept pull requests. We leave that up to the repo owner. The owner is already defined for most repos in the git.kbase.us system, and I’m just going with that, and some common sense on who is the owner in case it is not specified in git.kbase.us config files. Finally, there is a small group who are owners of the kbase organization. These folks have permission across all teams and repos. This is basically the same set of folks who have gitosis admin privileges on gitosis.conf. I should be done with this by mid next week depending on how quickly the License gets committed to the repos. On May 16, 2014, at 1:30 PM, Brettin, Thomas S. <brettin(a)anl.gov> wrote: > Hey Shane. Can u do me a favor and grab the license out of the assembly repo at gtihub and either pass it around the LBL team or just commit it in their repos? > > I'll migrate repos once the license has been committed. I'm almost done with the mostly ANL repos. But still some more to do. > > I'll be working on this more in a few hrs. > > Thanks > > Sent from my Verizon Wireless 4G LTE DROID > > > Shane Canon <scanon(a)lbl.gov> wrote: > > > Nomi, > > I’ll leave the disk image discussion to others. > > Dan and I talked about the version feature this morning. We think it is useful for several purposes and we (the project) should just commit to it. > > Regarding redeploys, I’ve been buried this week and I’m hesitant to start something major that could destabilize things on a Friday. So Dan and I plan to tackle this first thing Monday. Just to be clear, redploying the FBA service itself is easy. The part that concerns me is redeploying the updates for IRIS and getting that all correct. We’ve also seen some cases where we did a redeploy thinking it would be fairly contained and it wound up breaking something. Just one more reason for why we need the CI. > > —Shane > > > > > On May 15, 2014, at 9:34 AM, Nomi Harris <nlharris(a)lbl.gov> wrote: > >> Since I won’t be able to attend the release meeting today (I’m available tomorrow, but Dan doesn’t work Fridays), here are some of my thoughts about releases and disk images. I’m including below a message I wrote on the topic in December, most of which still applies. I would again encourage you to weigh the benefit of producing the disk images against the human effort required to build them. I know Rick uses the DMG, and it is also useful for testing. Also, the process of creating and testing the images often exposes (and motivates us to fix) issues in the build/deploy process and/or with individual services. I have asked Erik if we can determine from the website analytics how many times the disk images were downloaded; I will let you know what he finds. >> >> It’s very important that we start attaching version information to every service, and making it available in a standardized way (via the API and via a command-line arg, e.g. —version). This is important both for internal development and particularly if we want outside developers to integrate services. Every service should also describe the input/output formats it uses, so that services can be chained together in workflows. >> >> Every more pressing is that we need to do a new deploy of some services ASAP, particularly FBA modeling, which I believe has fixes that Chris has made recently that address issues that many users have complained about. I think workspace may need to be redeployed as well. We have tutorials in which everything worked back in October that have since broken; we need to get back to at least the level of functionality we had in October. >> >> Also, the renewal proposal referred to some new services that are not yet publicly deployed, so we need to get those deployed as soon as we can (e.g., Bambi, MAK). That may be more involved than redeploying our existing services, since it will be the first deploy of these new services. >> >> I hope someone will take meeting notes today. Sorry I can’t attend. >> >> Nomi >> >> Begin forwarded message: >> >>> From: Nomi Harris <nlharris(a)lbl.gov> >>> Subject: Release products: services, dmg (?), Iris >>> Date: December 3, 2013 at 11:03:48 AM PST >>> To: "Tom S. Brettin" <Brettin(a)mcs.anl.gov>, Adam Arkin <aparkin(a)lbl.gov> >>> Cc: Nomi Harris <nlharris(a)lbl.gov> >>> >>> Hi Tom, >>> As you noted, there is a lack of clarity about what it means to have a release. In my view, right now there are three categories of release product: >>> 1. Services. From a user perspective, it is hard to tell when a service has been updated. I would suggest that there should be a client command that asks the server its version number/datestamp. This would be particularly useful in cases where a change to a service API might break some methods in the client—the client might want to interrogate the service about what version it is. >>> 2. DMG/Ubuntu image. You mentioned that some people don’t think it’s worth the time and effort to put these together, but I wasn’t clear which side of the fence you fell on. I can definitely see both sides of this. I think these images are used by a small minority of power users, and that most people who use them either should be sticking with Iris, or, if they are developers, going the next step to using the Magellan images. It’s also clear that creating these images still requires significant human time—it would be nice if one could just type “make dmg” and it would all magically happen, but I gather there’s a fair amount of tinkering that’s necessary to make that work, and it might not be worth the effort. On the other hand, the dmg and ubuntu image are possibly the most visible release products, and that does count for something. >>> 3. Iris. Until the Narrative is publicly available, it seems to me that Iris is the most visible measure of progress. Jim has made Iris show a version number and datestamp, so that users can tell when it was updated and what’s new: >>> <Screen Shot 2013-12-03 at 10.34.25 AM.png> >>> >>> This makes it clear that Iris indeed has not been redeployed—not even in October. >>> Do you want me to ask Dan (and Jim) about that, so we can figure out what’s holding that up? >>> >>> 4. There’s a fourth thing that might be viewed as a release “product”, which is the data. It would be great if we could put something on our website after each data build that says the date of the data build and what’s new (N new data types [list], X new genomes, etc.). >>> >>> In summary, I would propose that a (software) release consists of: >>> - Release team does an integrity check on services to be (re)deployed—passes tests, has appropriate documentation (including release notes) >>> - Redeployment of updated services and deployment of new services >>> - Iris updated on public site >>> - Internal announcement from the release team that the release has happened, including a list of which services are new and which are changed in this release (and presumably the info about what’s changed is included in the service release notes) >>> - Public announcement (which I am happy to put together, given the info about what’s new/changed) to be posted to kbase.us >>> >>> I think the dmg/ubuntu images are optional in this process. >>> >>> Does this seem reasonable? >>> >>> Nomi >> >> >> >> _______________________________________________ >> Release-team mailing list >> Release-team(a)lists.kbase.us >> https://lists.kbase.us/mailman/listinfo/release-team > > _______________________________________________ > Release-team mailing list > Release-team(a)lists.kbase.us > https://lists.kbase.us/mailman/listinfo/release-team

1 0

Re: [Release-team] Release priorities
by Brettin, Thomas S. 16 May '14

16 May '14

Hey Shane. Can u do me a favor and grab the license out of the assembly repo at gtihub and either pass it around the LBL team or just commit it in their repos? I'll migrate repos once the license has been committed. I'm almost done with the mostly ANL repos. But still some more to do. I'll be working on this more in a few hrs. Thanks Sent from my Verizon Wireless 4G LTE DROID Shane Canon <scanon(a)lbl.gov> wrote: Nomi, I’ll leave the disk image discussion to others. Dan and I talked about the version feature this morning. We think it is useful for several purposes and we (the project) should just commit to it. Regarding redeploys, I’ve been buried this week and I’m hesitant to start something major that could destabilize things on a Friday. So Dan and I plan to tackle this first thing Monday. Just to be clear, redploying the FBA service itself is easy. The part that concerns me is redeploying the updates for IRIS and getting that all correct. We’ve also seen some cases where we did a redeploy thinking it would be fairly contained and it wound up breaking something. Just one more reason for why we need the CI. —Shane On May 15, 2014, at 9:34 AM, Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> wrote: Since I won’t be able to attend the release meeting today (I’m available tomorrow, but Dan doesn’t work Fridays), here are some of my thoughts about releases and disk images. I’m including below a message I wrote on the topic in December, most of which still applies. I would again encourage you to weigh the benefit of producing the disk images against the human effort required to build them. I know Rick uses the DMG, and it is also useful for testing. Also, the process of creating and testing the images often exposes (and motivates us to fix) issues in the build/deploy process and/or with individual services. I have asked Erik if we can determine from the website analytics how many times the disk images were downloaded; I will let you know what he finds. It’s very important that we start attaching version information to every service, and making it available in a standardized way (via the API and via a command-line arg, e.g. —version). This is important both for internal development and particularly if we want outside developers to integrate services. Every service should also describe the input/output formats it uses, so that services can be chained together in workflows. Every more pressing is that we need to do a new deploy of some services ASAP, particularly FBA modeling, which I believe has fixes that Chris has made recently that address issues that many users have complained about. I think workspace may need to be redeployed as well. We have tutorials in which everything worked back in October that have since broken; we need to get back to at least the level of functionality we had in October. Also, the renewal proposal referred to some new services that are not yet publicly deployed, so we need to get those deployed as soon as we can (e.g., Bambi, MAK). That may be more involved than redeploying our existing services, since it will be the first deploy of these new services. I hope someone will take meeting notes today. Sorry I can’t attend. Nomi Begin forwarded message: From: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> Subject: Release products: services, dmg (?), Iris Date: December 3, 2013 at 11:03:48 AM PST To: "Tom S. Brettin" <Brettin(a)mcs.anl.gov<mailto:[email protected]>>, Adam Arkin <aparkin(a)lbl.gov<mailto:[email protected]>> Cc: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> Hi Tom, As you noted, there is a lack of clarity about what it means to have a release. In my view, right now there are three categories of release product: 1. Services. From a user perspective, it is hard to tell when a service has been updated. I would suggest that there should be a client command that asks the server its version number/datestamp. This would be particularly useful in cases where a change to a service API might break some methods in the client—the client might want to interrogate the service about what version it is. 2. DMG/Ubuntu image. You mentioned that some people don’t think it’s worth the time and effort to put these together, but I wasn’t clear which side of the fence you fell on. I can definitely see both sides of this. I think these images are used by a small minority of power users, and that most people who use them either should be sticking with Iris, or, if they are developers, going the next step to using the Magellan images. It’s also clear that creating these images still requires significant human time—it would be nice if one could just type “make dmg” and it would all magically happen, but I gather there’s a fair amount of tinkering that’s necessary to make that work, and it might not be worth the effort. On the other hand, the dmg and ubuntu image are possibly the most visible release products, and that does count for something. 3. Iris. Until the Narrative is publicly available, it seems to me that Iris is the most visible measure of progress. Jim has made Iris show a version number and datestamp, so that users can tell when it was updated and what’s new: <Screen Shot 2013-12-03 at 10.34.25 AM.png> This makes it clear that Iris indeed has not been redeployed—not even in October. Do you want me to ask Dan (and Jim) about that, so we can figure out what’s holding that up? 4. There’s a fourth thing that might be viewed as a release “product”, which is the data. It would be great if we could put something on our website after each data build that says the date of the data build and what’s new (N new data types [list], X new genomes, etc.). In summary, I would propose that a (software) release consists of: - Release team does an integrity check on services to be (re)deployed—passes tests, has appropriate documentation (including release notes) - Redeployment of updated services and deployment of new services - Iris updated on public site - Internal announcement from the release team that the release has happened, including a list of which services are new and which are changed in this release (and presumably the info about what’s changed is included in the service release notes) - Public announcement (which I am happy to put together, given the info about what’s new/changed) to be posted to kbase.us<http://kbase.us/> I think the dmg/ubuntu images are optional in this process. Does this seem reasonable? Nomi _______________________________________________ Release-team mailing list Release-team(a)lists.kbase.us<mailto:[email protected]> https://lists.kbase.us/mailman/listinfo/release-team

1 0

Re: [Release-team] Release priorities
by Brettin, Thomas S. 16 May '14

16 May '14

the disk images need versions too. Did this get covered? Sent from my Verizon Wireless 4G LTE DROID Shane Canon <scanon(a)lbl.gov> wrote: Nomi, I’ll leave the disk image discussion to others. Dan and I talked about the version feature this morning. We think it is useful for several purposes and we (the project) should just commit to it. Regarding redeploys, I’ve been buried this week and I’m hesitant to start something major that could destabilize things on a Friday. So Dan and I plan to tackle this first thing Monday. Just to be clear, redploying the FBA service itself is easy. The part that concerns me is redeploying the updates for IRIS and getting that all correct. We’ve also seen some cases where we did a redeploy thinking it would be fairly contained and it wound up breaking something. Just one more reason for why we need the CI. —Shane On May 15, 2014, at 9:34 AM, Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> wrote: Since I won’t be able to attend the release meeting today (I’m available tomorrow, but Dan doesn’t work Fridays), here are some of my thoughts about releases and disk images. I’m including below a message I wrote on the topic in December, most of which still applies. I would again encourage you to weigh the benefit of producing the disk images against the human effort required to build them. I know Rick uses the DMG, and it is also useful for testing. Also, the process of creating and testing the images often exposes (and motivates us to fix) issues in the build/deploy process and/or with individual services. I have asked Erik if we can determine from the website analytics how many times the disk images were downloaded; I will let you know what he finds. It’s very important that we start attaching version information to every service, and making it available in a standardized way (via the API and via a command-line arg, e.g. —version). This is important both for internal development and particularly if we want outside developers to integrate services. Every service should also describe the input/output formats it uses, so that services can be chained together in workflows. Every more pressing is that we need to do a new deploy of some services ASAP, particularly FBA modeling, which I believe has fixes that Chris has made recently that address issues that many users have complained about. I think workspace may need to be redeployed as well. We have tutorials in which everything worked back in October that have since broken; we need to get back to at least the level of functionality we had in October. Also, the renewal proposal referred to some new services that are not yet publicly deployed, so we need to get those deployed as soon as we can (e.g., Bambi, MAK). That may be more involved than redeploying our existing services, since it will be the first deploy of these new services. I hope someone will take meeting notes today. Sorry I can’t attend. Nomi Begin forwarded message: From: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> Subject: Release products: services, dmg (?), Iris Date: December 3, 2013 at 11:03:48 AM PST To: "Tom S. Brettin" <Brettin(a)mcs.anl.gov<mailto:[email protected]>>, Adam Arkin <aparkin(a)lbl.gov<mailto:[email protected]>> Cc: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> Hi Tom, As you noted, there is a lack of clarity about what it means to have a release. In my view, right now there are three categories of release product: 1. Services. From a user perspective, it is hard to tell when a service has been updated. I would suggest that there should be a client command that asks the server its version number/datestamp. This would be particularly useful in cases where a change to a service API might break some methods in the client—the client might want to interrogate the service about what version it is. 2. DMG/Ubuntu image. You mentioned that some people don’t think it’s worth the time and effort to put these together, but I wasn’t clear which side of the fence you fell on. I can definitely see both sides of this. I think these images are used by a small minority of power users, and that most people who use them either should be sticking with Iris, or, if they are developers, going the next step to using the Magellan images. It’s also clear that creating these images still requires significant human time—it would be nice if one could just type “make dmg” and it would all magically happen, but I gather there’s a fair amount of tinkering that’s necessary to make that work, and it might not be worth the effort. On the other hand, the dmg and ubuntu image are possibly the most visible release products, and that does count for something. 3. Iris. Until the Narrative is publicly available, it seems to me that Iris is the most visible measure of progress. Jim has made Iris show a version number and datestamp, so that users can tell when it was updated and what’s new: <Screen Shot 2013-12-03 at 10.34.25 AM.png> This makes it clear that Iris indeed has not been redeployed—not even in October. Do you want me to ask Dan (and Jim) about that, so we can figure out what’s holding that up? 4. There’s a fourth thing that might be viewed as a release “product”, which is the data. It would be great if we could put something on our website after each data build that says the date of the data build and what’s new (N new data types [list], X new genomes, etc.). In summary, I would propose that a (software) release consists of: - Release team does an integrity check on services to be (re)deployed—passes tests, has appropriate documentation (including release notes) - Redeployment of updated services and deployment of new services - Iris updated on public site - Internal announcement from the release team that the release has happened, including a list of which services are new and which are changed in this release (and presumably the info about what’s changed is included in the service release notes) - Public announcement (which I am happy to put together, given the info about what’s new/changed) to be posted to kbase.us<http://kbase.us/> I think the dmg/ubuntu images are optional in this process. Does this seem reasonable? Nomi _______________________________________________ Release-team mailing list Release-team(a)lists.kbase.us<mailto:[email protected]> https://lists.kbase.us/mailman/listinfo/release-team

1 0

Re: [Release-team] Release priorities
by Brettin, Thomas S. 16 May '14

16 May '14

Thanks Shane. Sent from my Verizon Wireless 4G LTE DROID Shane Canon <scanon(a)lbl.gov> wrote: Nomi, I’ll leave the disk image discussion to others. Dan and I talked about the version feature this morning. We think it is useful for several purposes and we (the project) should just commit to it. Regarding redeploys, I’ve been buried this week and I’m hesitant to start something major that could destabilize things on a Friday. So Dan and I plan to tackle this first thing Monday. Just to be clear, redploying the FBA service itself is easy. The part that concerns me is redeploying the updates for IRIS and getting that all correct. We’ve also seen some cases where we did a redeploy thinking it would be fairly contained and it wound up breaking something. Just one more reason for why we need the CI. —Shane On May 15, 2014, at 9:34 AM, Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> wrote: Since I won’t be able to attend the release meeting today (I’m available tomorrow, but Dan doesn’t work Fridays), here are some of my thoughts about releases and disk images. I’m including below a message I wrote on the topic in December, most of which still applies. I would again encourage you to weigh the benefit of producing the disk images against the human effort required to build them. I know Rick uses the DMG, and it is also useful for testing. Also, the process of creating and testing the images often exposes (and motivates us to fix) issues in the build/deploy process and/or with individual services. I have asked Erik if we can determine from the website analytics how many times the disk images were downloaded; I will let you know what he finds. It’s very important that we start attaching version information to every service, and making it available in a standardized way (via the API and via a command-line arg, e.g. —version). This is important both for internal development and particularly if we want outside developers to integrate services. Every service should also describe the input/output formats it uses, so that services can be chained together in workflows. Every more pressing is that we need to do a new deploy of some services ASAP, particularly FBA modeling, which I believe has fixes that Chris has made recently that address issues that many users have complained about. I think workspace may need to be redeployed as well. We have tutorials in which everything worked back in October that have since broken; we need to get back to at least the level of functionality we had in October. Also, the renewal proposal referred to some new services that are not yet publicly deployed, so we need to get those deployed as soon as we can (e.g., Bambi, MAK). That may be more involved than redeploying our existing services, since it will be the first deploy of these new services. I hope someone will take meeting notes today. Sorry I can’t attend. Nomi Begin forwarded message: From: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> Subject: Release products: services, dmg (?), Iris Date: December 3, 2013 at 11:03:48 AM PST To: "Tom S. Brettin" <Brettin(a)mcs.anl.gov<mailto:[email protected]>>, Adam Arkin <aparkin(a)lbl.gov<mailto:[email protected]>> Cc: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> Hi Tom, As you noted, there is a lack of clarity about what it means to have a release. In my view, right now there are three categories of release product: 1. Services. From a user perspective, it is hard to tell when a service has been updated. I would suggest that there should be a client command that asks the server its version number/datestamp. This would be particularly useful in cases where a change to a service API might break some methods in the client—the client might want to interrogate the service about what version it is. 2. DMG/Ubuntu image. You mentioned that some people don’t think it’s worth the time and effort to put these together, but I wasn’t clear which side of the fence you fell on. I can definitely see both sides of this. I think these images are used by a small minority of power users, and that most people who use them either should be sticking with Iris, or, if they are developers, going the next step to using the Magellan images. It’s also clear that creating these images still requires significant human time—it would be nice if one could just type “make dmg” and it would all magically happen, but I gather there’s a fair amount of tinkering that’s necessary to make that work, and it might not be worth the effort. On the other hand, the dmg and ubuntu image are possibly the most visible release products, and that does count for something. 3. Iris. Until the Narrative is publicly available, it seems to me that Iris is the most visible measure of progress. Jim has made Iris show a version number and datestamp, so that users can tell when it was updated and what’s new: <Screen Shot 2013-12-03 at 10.34.25 AM.png> This makes it clear that Iris indeed has not been redeployed—not even in October. Do you want me to ask Dan (and Jim) about that, so we can figure out what’s holding that up? 4. There’s a fourth thing that might be viewed as a release “product”, which is the data. It would be great if we could put something on our website after each data build that says the date of the data build and what’s new (N new data types [list], X new genomes, etc.). In summary, I would propose that a (software) release consists of: - Release team does an integrity check on services to be (re)deployed—passes tests, has appropriate documentation (including release notes) - Redeployment of updated services and deployment of new services - Iris updated on public site - Internal announcement from the release team that the release has happened, including a list of which services are new and which are changed in this release (and presumably the info about what’s changed is included in the service release notes) - Public announcement (which I am happy to put together, given the info about what’s new/changed) to be posted to kbase.us<http://kbase.us/> I think the dmg/ubuntu images are optional in this process. Does this seem reasonable? Nomi _______________________________________________ Release-team mailing list Release-team(a)lists.kbase.us<mailto:[email protected]> https://lists.kbase.us/mailman/listinfo/release-team

1 0