| Summary: | in 'variables' API, the 'changed' field seems to return always 'FALSE' | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Toaster | Reporter: | Belen Barros Pena <belen.barros.pena> |
| Component: | toaster | Assignee: | Alexandru Damian <alexandru.damian> |
| Status: | VERIFIED OBSOLETE | QA Contact: | Bogdan Alexandru Voiculescu <bogdanx.a.voiculescu> |
| Severity: | enhancement | ||
| Priority: | Low | CC: | alexandru.c.georgescu, alexandru.damian, belen.barros.pena, bluelightning, bogdanx.a.voiculescu, cristiana.voicu, jessica.zhang, richard.purdie |
| Version: | 1.5 | ||
| Target Milestone: | 1.9 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | Moved from Cristiana to Unassigned | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Belen Barros Pena
2013-09-18 10:06:48 UTC
Hi Belen, I don't understand what 'changed' field is. Can you please give more details? Thank you! (In reply to comment #1) > Hi Belen, > I don't understand what 'changed' field is. Can you please give more > details? That is a very good question. The answer is: I don't know. We need to sit down and define what 'changed' means. It could be: * Changed from YP default value (which I am not even sure we can track) * Change since the previous build, which hopefully we can track. Users we spoke to seemed to want a way to narrow down which variables could be the source of a build failure (if my previous build completed, but the current one didn't, it is reasonable to assume that the cause of the failure is in something I've changed). We'll probably need to pick Paul's brain here, since his experience with build history might point us in the right direction. In any case, milestone for this should be 1.6 (just changed it). > Thank you! I need more information for this bug. Thanks the field is not needed. proper "changed" determination behaviour is to be documented in the "Configuration / Show variables" page, and will be determined by comparing the history of the value field across past build. (In reply to comment #4) > the field is not needed. > > proper "changed" determination behaviour is to be documented in the > "Configuration / Show variables" page, and will be determined by comparing > the history of the value field across past build. Most likely we'll add a "Changed" column to the variables table that will include a filter to show only variables changed since the previous build. With this in mind, do we still think we can work out the 'changed' status in the application, instead of storing it as a field in the database? By the way, any input on the previous build definition would be very welcome. We had a quick conversation about this issue yesterday. The outcome of the discussion was: * It should be possible to determine the "changed" status for a variable without adding an additional field to the database * In the first version, the previous build against which the 'changed' status is determined is not selected by users, i.e. you will not be able to choose to which build you'd like to compare the current build in order to determine what variables changed. This custom build comparison feature might be added later. * The above means that the application must determine what constitutes the previous build, and for that we need a definition of "previous build". What needs to match between two builds in order to make meaningful comparisons? We have also decided that although this feature is important and useful, we are in no position to bring it in for 1.6, so changing milestone to 1.7 So in case it's not clear, this is effectively unimplemented functionality rather than a bug at this stage, so I'm marking it as an enhancement. This was about providing a way to compare the value of a variable between builds, to see if it had changed. This is covered by bug 6840. verified as obsolete |