1 |
On Fri, Sep 23, 2011 at 4:26 PM, Nikos Chantziaras <realnc@×××××.de> wrote: |
2 |
> On 09/24/2011 02:10 AM, Matt Turner wrote: |
3 |
>> |
4 |
>> On Fri, Sep 23, 2011 at 5:44 PM, Nikos Chantziaras<realnc@×××××.de> |
5 |
>> wrote: |
6 |
>>> |
7 |
>>> I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2 |
8 |
>>> packages currently in the tree. The maintainer of zlib pushed those |
9 |
>>> revisions with a patch that alters macro identifiers, making Gentoo's |
10 |
>>> zlib |
11 |
>>> incompatible with upstream. As a result, a lot of packages stopped |
12 |
>>> building. Bug reports for broken packages come in and then are being |
13 |
>>> modified to fit Gentoo's zlib. |
14 |
>>> |
15 |
>>> Breaking compatibility with upstream zlib also means that non-portage |
16 |
>>> software, the ones I install with "./configure --prefix=$HOME/usr&& make |
17 |
>>> install", also won't build. |
18 |
>>> [...] |
19 |
>> |
20 |
>> It seemed to me like this was a silly problem from the outset. vapier |
21 |
>> did arguably the right thing, and if that means exposing some broken |
22 |
>> software, fine. We handle plenty of breakage worse than this, but I |
23 |
>> understand that it can be inconvenient. |
24 |
>> |
25 |
>> However, you completely lost any support when you said |
26 |
>> |
27 |
>>> Yes, bad idea. But it's in my liberty to write code however I see fit. |
28 |
>> |
29 |
>> That just makes me want to slap you. |
30 |
>> |
31 |
>> I'll echo what vapier said in response: it's absolutely your |
32 |
>> prerogative to do whatever you want, but it's not our responsibility |
33 |
>> to make sure that it works in Gentoo. |
34 |
> |
35 |
> The code is perfectly valid. You cannot force people to follow your coding |
36 |
> standards. If it's valid C code, it doesn't matter that it contradicts your |
37 |
> personal preferences. It's not your code and you don't have a saying in it. |
38 |
> What's next, banning software that indents code with tabs instead of |
39 |
> spaces? |
40 |
|
41 |
You are allowed to disagree with his changes; but that doesn't mean we |
42 |
must listen to you. |
43 |
I actually disagree with Vapier as well (I don't see why we would act |
44 |
without waiting for upstream) but I also trust his technical ability |
45 |
in matters like this. |
46 |
|
47 |
> |
48 |
> |
49 |
>>> It's a bad call. You've made plenty of those lately. This is just another |
50 |
>>> one. |
51 |
>>> IMO, you don't have the skills and insight to mess with this stuff. So |
52 |
>>> when you |
53 |
>>> try, breakage happens. I hope you retire soon. |
54 |
>> |
55 |
>> Are you kidding me? Grow up. |
56 |
> |
57 |
> This was just another episode of Vapier's hostile and arrogant behavior |
58 |
> towards users. Every time someone comes up with a valid argument of why |
59 |
> he's wrong, the final answer is "don't care, I do what I please because I'm |
60 |
> the dev and you're not." So my reply was the politest I could come up with |
61 |
> without using the f-word. |
62 |
|
63 |
I'm curious what you think the final answer should be? |
64 |
|
65 |
-A |
66 |
|
67 |
> |
68 |
> |
69 |
> |