On Fri, Aug 15, 2008 at 12:55:12AM -0400, Andrew D Kirch wrote: > Here's the script that I used to generate this. I have not manually > reviewed all of thousands of patches to determine the unique situation of > each patch, however I would like a suggestion on how to demonstrate _real_ > statistics short of auditing each and every patch in portage which I > personally don't have time to do. Ok, even this misses lots of patches.
As a suggestion on count improvements, look for invocations of epatch. They will take the following variations: 1. Use of a single file from $FILESDIR 2. Use of a single file from some distfile 3. Use of a directory from $FILESDIR 4. Use of a directory from some distfile Cases #1 and #2 will cover probably 95% of packages. Cases #3 and #4 will however contribute a lot to your stats. For MySQL as an example: http://git.overlays.gentoo.org/gitweb/?p=proj/mysql-extras.git;a=summary We carry 64 different patches. In some cases like 080_all_slot_script-*, it's 10 different versions of the same patch, that apply to different upstream releases. Lots of the patches are backports from upstream for bugs or security, because their release schedule isn't co-operative with often. 15 of the total 64 files have comment headers, esp. where the patch was a newer respin of some old one - I've been adding comment blocks. None of the patches in the mysql set are new features. Tracking epatch with grep (not hooking it, because of conditional patching) will get you a better count of overall patches, but not the distribution of patches in ebuilds. One other common case to watch for, is cases where we just borrow some of all of the debian patchset for a package. In general, I do see your interest in pushing patches upstream, but as both an upstream author and a downstream maintainer, I ask you to consider all distributions equally. Per my experiences as upstream (spanning 6+ packages I've written over the years): - Ubuntu seems to have a particularly bad track record with sending patches upstream. As the author of readahead-list (which is in a lot of distros), I've specifically mailed the Ubuntu maintainer and asked that he send me tidied up versions of the patches (I had some specific concerns) - and they totally ignored the newer version released a year later. I've heard precisely nothing back from them ever. In the case of readahead-list, they have two nice feature patches, and one bugfix. For a couple of my other packages, I have neither asked nor received anything from them, but I do see them carrying feature patches. - FreeBSD has a decent track record, I've received patches for a few different bugs and new features. RedHat/Fedora are pretty good as well. Negative experiences as a downstream maintainer: - Some upstreams ignored you - For Gitosis (see gitosis-gentoo and gitosis packages). Upstream has never accepted or even acknowledged any of the feature or bugfix patches I've sent him. This won't show up as a patch in your counts, because I now maintain gitosis-gentoo as a fork of the original because of the lack of upstream input. - Some upstreams attack you - For foo2zjs, I was outright textually assaulted by the author when I submitted a patch for a page rotation bug - he demands that nobody use any third-party packaging and install it entirely manually if they want any support - despite the fact I was submitting a bugfix and not asking for anything. - Stubborn upstreams - an upstream denied for a long time that one thing I suspected of being an issue was really at fault. It took me several months of detailed debugging to conclusively prove it (the upstream in question ran on a BSD system and didn't realize a subtle Linux difference). - Requirements of paperwork and contribution rules - Some GNU/FSF projects are pretty bad in this regard, wanting signed paperwork to have a patch included in the upstream, even if it's a bugfix. - Strenuous submission process, this is a less degree of a problem, but some larger upstreams are extremely picky about submissions. I've had to revise a bugfix 5-6 times before from using the style of the existing code to match the style of the new requirements instead. - Effective contribution channels - For MySQL, I've never had a patch that I submitted directly to the upstream bug tracking system accepted, but all the patches I addressed directly to a developer that I knew was reasonable for that portion of the codebase made it in. Some positive experiences as downstream: - Linux Kernel. Good patch submission review and ease of inclusion. I've got two good bugfixes you'll find in current kernels, plus I've done prototypes or spins of other patchsets that have been well received even if they weren't suitable for inclusion. - Danga (MogileFS). A couple of good patches then you get commit access. All commits are reviewed anyway. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpLGKWrNEOmS.pgp
Description: PGP signature
