Re: whether to use bugzilla or not

[Chris Chabot <chabotc reviewboard com>]

> A part of the misunderstanding may be what you are expecting from the .spec
> files in the tarballs. These .spec files are not really part of the packages
> the way the rest of the source is. None of the Linux distributions use these
> .spec files, as far as I know. They have their own .spec files (or
> equivalent, depending on what packaging scheme they use). And Ximian doesn't
> use them either.
>
> <snip>
>
> We don't really expect these .spec files to be in good shape for the alpha
>
> releases. Many of the maintainers don't actually maintain the .spec files in
> the packages.
> We could remove the .spec files just for clarity, but I think that might
> make things even worse.
Ok, i think this touches on a very real point.

I do indeed actualy expect working .spec files in a tarball, since for 
the average or casual user, it is the only way to be able to 
self-compile source code, without having to _totaly_ mess up their 
system. Remeber the time when people didnt use ximian's beta rpm's, and 
people had tons of different versions of .so's around, in both /opt, 
/usr and /usr/local... the support nightmare was complete, and the scary 
factor very high for anyone trying out cutting edge software.

Now i am not saying these .spec files have to be used by 
mandrake/ximian/redhat, etc.. however i do think they can offer a way 
for a user to try out new releases (test & file bug reports on releases, 
install the next version the next day, etc).

Especialy in these alpha / beta days, a lot of files will come and go 
from any package file list, and the only way to prevent file sys. 
polution in that case, is to use the .spec files (or alien them to .deps 
etc).

If it is to much of a engineering nightmare for maintainers to keep 
these .spec files up to date (or to darn confusing for them), i would 
sugest taking out the .spec file. I see no reason to ship _known broken_ 
tools and configurations, no matter what the side benifits might be... 
they only confuse & frustrate user type people, and will leave a bad 
impression of any release with a bad .spec file that the lazy / casual 
user will try (ie, "it failed to compile or work, what kind of release 
engineering is this?!")

However, since gnomehide & rawhide & ximain have plenty of well working 
.spec files for the gnome 2 platform, why not simply import those for 
the relavent packages, and have a well working rpm build system for the 
gnome 2 (vendor neutral) release?

Anyways, just my 0.02 euro cents... since i do use .spec files for my 
day to day boxes maintanance, and know quite a few people who do as well ;-)

Anyways, thaks for the replies. For now i'll just crusade for the 
working .spec files, and file all 'real' bug reports in bugzilla.

Ps, if the only thing holding working .spec files is a lack of man 
hours, i'd be more then willing to dive into the deep end of the pool, 
and maintain them. (though that might feel redundance, since so many 
people already do this)