[CentOS] Dag's comment at linuxtag

Wed Jul 1 19:09:46 UTC 2009
Dag Wieers <dag at wieers.com>

On Wed, 1 Jul 2009, Dag Wieers wrote:

> On Wed, 1 Jul 2009, Radu-Cristian FOTESCU wrote:
>
>> >    - audacious has a missing dependency (audacious-plugins)
>> >    - comix SRPM does not rebuild
>> > 
>> >  That's 2 packages, I think we do quite well if that is it :)
>>
>>  But this is only because I am not crazy enough to try 7,600 packages!
>
> Well, you said it was silly to have 8000 packages, while we should only 
> provide 400 that worked very well.
>
> I say that you only proved to me that 2 are not working well. I am unwilling 
> to drop 7600 packages because you report 2 that are broken.
>
> You see the difference :)
>
> Of course if you want to make the case that it is better to focus on quality 
> it is better to day that 7600 have problems, but you are actually lying 
> because you only know about 2 broken packages.
>
> Besides we don't have 8000 unique packages, more like 5000 I think. But that 
> is beside the point.

Now that I read this again, you only proved that 1 is broken, the other 
simply doesn't build for you. I have the proof it build for me :)

Maybe the BuildRequires are incorrect, because I work with static 
buildroots, not dynamic ones. And as a consequence my BuildRequires could 
be insufficient. (Doubtful because it was made by Dries)

Maybe the BuildRequires doesn't say exactly what version it needs. Because 
doing that would mean you have to go and see what the lowest version is 
with which is works. Which is time-consuming. (We do build from the same 
SPEC file for RHEL2, RH7, RH9, RHEL3, RHEL4 and RHEL5)

But that doesn't mean it is broken. It is certainly sub-optimal, and if 
you report such cases we do fix them.

Imagine that we would do exactly as you say, even then Radu-Christian² 
may state on this list with a lot of fanfare that certain packages we 
ship may not function properly because our process does not include 100% 
functional testing and we should dedicate our time to functionally test an 
RPM before shipping it. And drop any packages we don't do this for.

So this whole situation is not black and white. In fact if we would have
unlimited time, unlimited money or unlimited contributors I would consider 
your suggestions seriously. But right now, any effort would be hurting 
some other effort and I would rather have X new packages then spending the 
same time to remove Y other packages.

Because I think my time would simply be worth more spending on something 
else. You obviously do think this time would be worth spending, and have 
been told what is needed to get it fixed :) I don't want to be the person 
that denies improving what is suboptimal though.

So my offer for commit access still stands, in case you'd reconsider.

Kind regards,
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]