Hi David, Thanks for going through the design documents and for the questions / comments. I'll add an open to the Toaster call to discuss them (easier than email, I think).
Cheers Belén On 20/05/2015 07:57, "Reyna, David" <[email protected]> wrote: >Hi again, > >I am thinking about how on page 5 you expose the "Project ID" number. > >Are you sure you want to do that? That is an internal database integer >that I think should be absolutely hidden. It could also be volatile and >non-portable, if for example Alex should at some time in the future want >to be able to renormalize/port/rebalance the database. > >I would think that the "Project Name" should the true and proper key for >external lookup and access. > >If your concern is that the GUI user may randomly rename the project and >thus break the external connection, then perhaps there could be some >other unique and persistent ID that is created and associated with the >project so that we can we keep its database internal index integer out of >this, like how git has the commit ID instead of its database location. > >- David > >> -----Original Message----- >> From: Reyna, David >> Sent: Tuesday, May 19, 2015 3:26 PM >> To: BARROS PENA, BELEN; [email protected] >> Subject: RE: [Toaster] Design - dropping support for stand-alone >> analysis mode (7711) >> >> Hi Belén, >> >> I think that I am fine with this general design proposal. >> >> I have some comments and questions, mostly around the details for the >> not-yet-written "How to set up an analysis project" content. >> >> 1) Connecting Analysis Projects to External Builds? >> >> It appears that the connection of analysis project to its build >> directory and artifacts is solely managed by the external build system? >> I assume that this is the case given the complexity and diversity of >> possible external build systems? >> >> If that is the case, why do we support creating such project in the >> Toaster GUI? Is it perhaps to support a use case where the Toaster user >> would get the otherwise "unattached" project's ID number (on page 5) >> and enter it in the external build system to complete that connection? >> >> 2) Use case for current local analysis workflow? >> >> Today you would use the tool "source toaster start" to connect a >> specific build directory to a Toaster build, and the "external builder" >> is in fact the command line user that initiates the build(s). >> >> Will we still support this general workflow? In other words, could be >> provide the equivalent of ... >> >> $ cd <build_dir> >> $ source toaster start [project_id] >> $ bitbake core-image-base >> >> ... where some tool will be able to (a) attach this build to >> <project_id> if that parameter is passed, (b) find the Toaster project >> for this path if it exists and add this build, or (c) create a new >> Toaster analysis project on the fly if this directory path is not >> current used? >> >> I believe that this workflow is important because it provides >> functional backwards compatibility, is easy to integrate for both >> formal and informal "build managers", and provides an easy way for >> reluctant command line users to get into the benefits of the deep >> Toaster Analysis features. >> >> All of these reasons apply to Wind River and its use of Toaster. >> >> 3) Passing data from External Builder >> >> I assume that for external Build Managers the creation and population >> of an Analysis Project's builds is along the same lines as you have >> outlined in your Jenkins summary? >> >> In other words, contrary to your statement on page 3, Toaster does not >> simply "collect" build information, it actually simply "receives" that >> information and artifacts as passed by say the plug-in for Jenkins? >> >> Specifically, it would seem that (a) during the build the analysis data >> would be passed directly from that remote bitbake instance to the >> shared Toaster database, and then (b) upon success the selected build >> artifacts would then be also be passed by the integration plug-in. >> >> - David >> >> > -----Original Message----- >> > From: [email protected] [mailto:toaster- >> > [email protected]] On Behalf Of Barros Pena, Belen >> > Sent: Thursday, May 14, 2015 8:42 AM >> > To: [email protected] >> > Subject: [Toaster] Design - dropping support for stand-alone analysis >> > mode (7711) >> > >> > This Bugzilla feature >> > >> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7711 >> > >> > Has considerable impact on how users interact with projects. If you >> > can, >> > please check the design document attached to the Bugzilla feature and >> > comment as needed. >> > >> > Thanks! >> > >> > Belén >> > >> > >> > -- >> > _______________________________________________ >> > toaster mailing list >> > [email protected] >> > https://lists.yoctoproject.org/listinfo/toaster -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
