On 08/13/2010 06:45 PM, Luke Macken wrote:
On 08/13/2010 01:57 AM, Ralf Corsepius wrote:
> On 08/13/2010 01:23 AM, Luke Macken wrote:
>> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
>>> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
>>>> - Minimum time-in-testing requirements
>>>> - Every day bodhi will look for updates that have been
>>>> in testing for N days (fedora: N=7, epel: N=14), and
will
>>>> add a comment notifying the maintainer that the update
is
>>>> now able to be pushed to stable.
>>>
>>> Suppose I submit a package to testing and it gets pushed. Six days
>>> later, I find a terrible bug in the package (or a user reports this to
>>> me). I fix the package and edit the update, request the fixed package
>>> to be pushed to testing again and it gets pushed the next day.
>>>
>>> Now without any further testing the package can be pushed to stable,
>>> which contradicts the purpose of this whole change in bodhi.
>>>
>>> I think, for packages that are modified during the testing period,
>>> this N should be calculated from the day the last push was made to
>>> testing.
>
> This would very unhelpful.
>
>> Yes, this was my initial intention. However, looking at the code a bit
>> closer, your scenario would currently be allowed, as it currently only
>> calculates the time-in-testing based on the first push to testing.
> This behavior is helpful, because otherwise updates would "starve".
The only case for update starvation that I can think of is if you keep
adding/removing builds from an update before it reaches a week in
testing or the karma thresholds.
C.f. my other mail - Such cases happen.
Another scenario I haven't mentioned yet is packaging bugs.
One day, a packager fixes one, 4 days later he (or a tester) notices
another one, fixes it, 6 days later the next one is being fixed, ... ad
infinitum.
Now take dependency chains into account ...
Ralf