[elrepo] kmod-drbd83-8.3.10-1.el5.elrepo.x86_64.rpm - no kmod inside

[Phil Perry]

On 19/02/11 21:19, Dag Wieers wrote:
> On Sat, 19 Feb 2011, Phil Perry wrote:
>
>> On 19/02/11 16:20, Akemi Yagi wrote:
>>> On Sat, Feb 19, 2011 at 8:17 AM, Manuel Wolfshant
>>> <wolfy at nobugconsulting.ro>   wrote:
>>>> On 02/19/2011 05:29 PM, Rainer Traut wrote:
>>>
>>> Thanks, Rainer and Manuel.  We will look into the problem.
>>
>> it seems the default make modules_install stopped working for some
>> reason, so no modules got installed to the buildroot nor packaged.
>>
>> Thanks very much for reporting the issue.
>
> Apart from the cause (and obvious ways to prevent the same thing from
> happening) it's an interesting case in the discussion of the promotion of
> packages from testing to elrepo.
>
> What's the use of having the package for 2 weeks in testing, if it is only
> ever used when it hits elrepo. The only effect is that our packages are 2
> weeks late with no obvious benefits.
>
> This obviously changes my view on the automated promotion and the need for
> a testing repository, unless we can change the dynamics (although I don't
> see any obvious ways to make people use testing).
>
> My current thought is to only push packages to testing if there is a known
> need for testing, or if there's an established set of testers. (Some
> organisations use these packages, but the testing only happens when it
> fits their planning, and not ours, unfortunately)
>

Yes, I largely agree.

I say largely, because I'm slightly hesitant/cautious given the 
Enterprise nature of the project's audience and the expectancy that a 
certain level of quality will ensue. As we've discussed (internally) 
previously, it's largely determined on a case by case basis with the 
package maintainer responsible for making the decision rather than the 
existence of any hard and fast policy. But as you say, if there is no 
reason to suspect the packages may be broken/need additional testing, 
and/or there are no known testers for the package, there seems little 
point putting them in the testing repository.

Although in this case I think we failed to perform even the most basic 
of sanity checks on our package(s) so we must accept the blame for that 
and think about ways we can improve our processes so that doesn't happen 
again.