contributing a software through bugzilla

[Kevin Kofler]

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> Are you seriously telling me you would accept a package which has 30 or
> more patches applied? 

Why not? In fact, there are already such packages in Extras. For example, look 
at the ATLAS package. That one uses the "one big patch" approach, because there 
would be too many otherwise: there's a Debian gzipped patch applied which is 
3.8 MB _compressed_ (!) and then there's a 972 byte Fedora patch on top of that 
to use gfortran instead of g77. Some packages have upstreams which are either 
defunct or (as is probably the case of ATLAS) don't care about packaging and 
packagers' requirements, so there's no other solution there. Sure, if the 
patches could go upstream, it would be better, but if not, I don't see why 
having many or big patches would be a reason not to approve the packages.

Also, for a package like rtems-binutils, upstream is really RTEMS, not the FSF. 
So the big patch to get from FSF Binutils to RTEMS Binutils is not really a 
packager patch, it's just how upstream distributes its source code. Getting 
their local patches merged into the FSF source is something upstream would have 
to deal with, not the Fedora packager. TIGCC works similarly. (I currently have 
a 318 KB GCC patch and a 61 KB GNU as patch.)

        Kevin Kofler