| 1 |
On 04/27/2012 09:03 AM, Dirkjan Ochtman wrote: |
| 2 |
> Thanks for doing this! Sorry it took so long to review them... we |
| 3 |
> should try to think of some easier review mechanism than putting up a |
| 4 |
> tarball you have to unpack. |
| 5 |
> |
| 6 |
> On Sun, Apr 22, 2012 at 03:12, Mike Gilbert <floppym@g.o> wrote: |
| 7 |
>> If we can get some people testing these that would be great. I would |
| 8 |
>> like to add them to the tree sometime in the next week. |
| 9 |
> |
| 10 |
> I wonder, do you have a rationale for including each patch? IMO, |
| 11 |
> Arfrever has a tendency to diverge a bit further from upstream than I |
| 12 |
> like, and I note that you've taken in some patches and don't seem to |
| 13 |
> have gone in upstream. |
| 14 |
|
| 15 |
To be honest, I did not look into each patch in great detail. I really |
| 16 |
just tested the resulting builds to make sure they did not break |
| 17 |
anything obvious. |
| 18 |
|
| 19 |
That said, let's dive in! |
| 20 |
|
| 21 |
> These are the differences between my 2.7.3 |
| 22 |
> patchset and your 2.7.3-0: |
| 23 |
> |
| 24 |
> 1. Added 08_all_regenerate_platform-specific_modules.patch, which |
| 25 |
> doesn't seem to be upstream yet. |
| 26 |
|
| 27 |
Indeed it does not. Based on the feedback in the upstream bug, let's |
| 28 |
drop it. |
| 29 |
|
| 30 |
> 2. Added back 22_all_turkish_locale.patch, which AFAIK isn't upstream, |
| 31 |
> nor associated with an open upstream bug? |
| 32 |
|
| 33 |
I can't find a bug for this either. |
| 34 |
|
| 35 |
> 3. Added 61_all_process_data.patch, for which the goal seems somewhat unclear. |
| 36 |
> |
| 37 |
|
| 38 |
This is some logic for python-wrapper that was in the 2.7.2 patchset as |
| 39 |
well. If you want to drop it, I'm sure that will require some |
| 40 |
re-engineering of python-wrapper. |
| 41 |
|
| 42 |
> You also removed the mention of the upstream bug from |
| 43 |
> 04_all_libdir.patch, probably just by mistake? |
| 44 |
> |
| 45 |
|
| 46 |
I don't see any mention of a bug in the 2.7.2, 2.7.3 or 2.7.3-0 version |
| 47 |
of the patch, so I'm not sure what you are referring to here. |
| 48 |
|
| 49 |
> As for 3.2.3, I'm also -1 on including 23_all_h2py_encoding.patch |
| 50 |
> after reading http://bugs.python.org/issue13032. |
| 51 |
|
| 52 |
Agreed. |
| 53 |
|
| 54 |
> Including |
| 55 |
> 26_all_gdbm-1.9.patch in 3.1.5 is probably a good idea. For 3.1.5's |
| 56 |
> 09_all_sys.platform_linux2.patch, I'd prefer if we just reuse |
| 57 |
> ${FILESDIR}/linux2.patch, unless that doesn't apply for some reason. |
| 58 |
|
| 59 |
I don't really see a difference either way. I guess it is more visible |
| 60 |
in the ebuild. |
| 61 |
|
| 62 |
> Now, we can certainly discuss adding these patches on this list, but I |
| 63 |
> think we should try to maintain some balance on the upside of having |
| 64 |
> extra fixes in our ebuilds and the amount of maintenance we're willing |
| 65 |
> to do on carrying those patches forward (e.g. the distutils patch is a |
| 66 |
> pretty big pain, and it seems like more of a feature than a bug). |
| 67 |
|
| 68 |
Well, that does seem to be Arfrever's baby, so as long as he keeps |
| 69 |
rebase it, we should be ok. |
| 70 |
|
| 71 |
> I don't think we should throw everything out on revbumps or bugfix |
| 72 |
> releases, but for new releases such as 3.3 I would personally like to |
| 73 |
> do only the bare minimum of patching. |
| 74 |
> |
| 75 |
|
| 76 |
That makes sense. I will keep it in mind. |
| 77 |
|
| 78 |
Would you like me to cut a new set of tarballs without 08, 22, and 23? |
Archives