questions on 7177 Most built target fixes

questions on 7177 Most built target fixes

[Lerner, Dave]

Hi Belen,
For https://bugzilla.yoctoproject.org/show_bug.cgi?id=7177 ...

1) I don't think that the spec matches the code.  The spec states only completed builds (and I assume you mean Failures and Successes). I see the code in the 1st line below, but then the code also has an additional line that explicitly adds queued and created build requests.    
  freqtargets += ... Build.objects.filter(project = prj, outcome__lt = Build.IN_PROGRESS... 
  freqtargets += ... BuildRequest.objects.filter(project = prj, 
                          state__lte = BuildRequest.REQ_QUEUED
Is the code correct and I am not understanding the relationship between tables BuildRequest and Build and your spec? Or as long as I'm in this module do I need to delete that second line which adds created and queued build requests that haven't completed?  

While the code presented in the opposite sort order, causing the wrong sort that you observed, the additional incomplete builds from the BuildRequest table may also have contributed to the list looking incorrect.

2) It's trivial to limit the most built list to 5 in decreasing order of a target's build counts. But the spec states that the sort order is multi key sort, {counts-per-target descending, date of build completion descending).  Do you still want the multi-key sort, {counts-per-target, completion-date} so that for example if 10 builds were all built once, the latest 5 are shown in build completion timestamp order?

Dave

Re: questions on 7177 Most built target fixes

[Barros Pena, Belen]

On 12/03/2015 22:19, "Lerner, Dave" <dave.lerner@windriver.com> wrote:

>Hi Belen,
>For https://bugzilla.yoctoproject.org/show_bug.cgi?id=7177 ...
>
>1) I don't think that the spec matches the code.  The spec states only
>completed builds (and I assume you mean Failures and Successes). I see
>the code in the 1st line below, but then the code also has an additional
>line that explicitly adds queued and created build requests.
>  freqtargets += ... Build.objects.filter(project = prj, outcome__lt =
>Build.IN_PROGRESS...
>  freqtargets += ... BuildRequest.objects.filter(project = prj,
>                          state__lte = BuildRequest.REQ_QUEUED
>Is the code correct and I am not understanding the relationship between
>tables BuildRequest and Build and your spec? Or as long as I'm in this
>module do I need to delete that second line which adds created and queued
>build requests that haven't completed?

This is a good question. I guess the answer is that 'build requests' are
an implementation concept: users don't know the difference between a build
and a build request. So what the list of targets should show is targets
for: 

1. completed builds (succeeded or failed)
2. and failed build requests

>
>While the code presented in the opposite sort order, causing the wrong
>sort that you observed, the additional incomplete builds from the
>BuildRequest table may also have contributed to the list looking
>incorrect.
>
>2) It's trivial to limit the most built list to 5 in decreasing order of
>a target's build counts.

This sounds good. Thank you.

> But the spec states that the sort order is multi key sort,
>{counts-per-target descending, date of build completion descending).  Do
>you still want the multi-key sort, {counts-per-target, completion-date}
>so that for example if 10 builds were all built once, the latest 5 are
>shown in build completion timestamp order?

This might be too much work, to be honest. I am happy if you can list the
top 5 targets per number of builds in decreasing order. When targets have
the same number of builds, we can choose which one to display in whatever
way is easiest (alphabetical order or some random thing: I am ok with
that).

Cheers

Belén

>
>Dave