Re: [gentoo-dev] The Plethora of Patches

[Robin H. Johnson]

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     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85