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