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

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

15 May '14

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 > >

1 0

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

15 May '14

Nomi, The scope of this is the downloadable things as per your original post to Jira. I’ll resend that email. You’re conflating the scope. These things are important, but they won’t be the topic of today;s call. Tom On May 15, 2014, at 11: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

1 0

Re: [Release-team] Release priorities
by Nomi L. Harris 15 May '14

15 May '14

Ok--Tom had given me the impression it was more of a hassle than that. If the DMG is that useful and easy to make, why hasn't it been updated since October? Nomi > On May 15, 2014, at 9:39 AM, Robert Olson <olson(a)mcs.anl.gov> wrote: > > Benefits: The most completely portable and effective release of KBase client software and libraries. Forces developers to make their software deploy. Enables distributed development of KBase applications and services. > > Cost: running a few scripts and putting a blurb on the website. > >> On May 15, 2014, at 11:37 AM, Nomi Harris <nlharris(a)lbl.gov> wrote: >> >> I did not say it should go away; I just said we should evaluate the cost/benefit ratio. Can you explain why it’s too valuable? >> Nomi >> >>> On May 15, 2014, at 9:35 AM, Robert Olson <olson(a)mcs.anl.gov> wrote: >>> >>> The DMG isn't going away. It is too valuable. >>> >>>> On May 15, 2014, at 11: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 >

1 0

Re: [Release-team] Release priorities
by Robert Olson 15 May '14

15 May '14

Benefits: The most completely portable and effective release of KBase client software and libraries. Forces developers to make their software deploy. Enables distributed development of KBase applications and services. Cost: running a few scripts and putting a blurb on the website. On May 15, 2014, at 11:37 AM, Nomi Harris <nlharris(a)lbl.gov> wrote: > I did not say it should go away; I just said we should evaluate the cost/benefit ratio. Can you explain why it’s too valuable? > Nomi > > On May 15, 2014, at 9:35 AM, Robert Olson <olson(a)mcs.anl.gov> wrote: > >> The DMG isn't going away. It is too valuable. >> >> On May 15, 2014, at 11: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 >> >

1 0

Re: [Release-team] Release priorities
by Nomi Harris 15 May '14

15 May '14

I did not say it should go away; I just said we should evaluate the cost/benefit ratio. Can you explain why it’s too valuable? Nomi On May 15, 2014, at 9:35 AM, Robert Olson <olson(a)mcs.anl.gov> wrote: > The DMG isn't going away. It is too valuable. > > On May 15, 2014, at 11: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 >

1 0

Re: [Release-team] Release priorities
by Robert Olson 15 May '14

15 May '14

The DMG isn't going away. It is too valuable. On May 15, 2014, at 11: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

1 0

Release priorities
by Nomi Harris 15 May '14

15 May '14

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: > > > 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

1 0

1:30 - 2:00 pm CDT Release Team Discussion
by Gordon, India S. 15 May '14

15 May '14

When: Thursday, May 15, 2014 1:30 PM-2:00 PM. (UTC-06:00) Central Time (US & Canada) Where: 888-850-4523, passcode: 416791, leader passcode (Tom only) 4167913 *~*~*~*~*~*~*~*~*~*

1 0

Re: [Release-team] it's time to release a new set of products
by Gordon, India S. 14 May '14

14 May '14

All, Good morning. Please indicate your availability tomorrow, May 15, 2014 between 12:00 – 3:00 pm CST. Sincerely, India From: <Brettin>, "Thomas S." <brettin(a)anl.gov<mailto:[email protected]>> Date: Tuesday, May 13, 2014 at 11:06 PM To: "release-team(a)lists.kbase.us<mailto:[email protected]>" <release-team(a)lists.kbase.us<mailto:[email protected]>> Subject: [Release-team] it's time to release a new set of products Resent-From: <marland(a)mcs.anl.gov<mailto:[email protected]>> 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 [cid:[email protected]]

1 0

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

13 May '14

Sounds good, thanks Bob. The construction of the DMG is in good shape. The remaining items need some discussion. Also, what qualifies as production-ready needs some discussion. On May 13, 2014, at 11:07 PM, Olson, Robert D. <olson(a)mcs.anl.gov> wrote: > All thing I need is the list of production-ready modules for inclusion into the dmg. > > From: release-team-bounces(a)lists.kbase.us [release-team-bounces(a)lists.kbase.us] on behalf of Thomas Brettin [brettin(a)anl.gov] > Sent: Tuesday, May 13, 2014 11:06 PM > To: release-team(a)lists.kbase.us > Subject: [Release-team] it's time to release a new set of products > > 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 > > <PastedGraphic-2.png>

1 0