New bodhi release in production

Ralf Corsepius rc040203 at freenet.de
Fri Aug 13 16:55:45 UTC 2010


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






More information about the devel mailing list