| 1 |
On Mon, Aug 27, 2012 at 10:05 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> That's all I'm saying. It's being made a whole lot less pleasant that it |
| 3 |
> might be... for what reason? Just to satisfy someone's ego that they're |
| 4 |
> right and can /force/ compliance? Yuck! |
| 5 |
|
| 6 |
Honestly, while I might agree with that sentiment on some of these |
| 7 |
threads, my only complaint with Ciaran's original response was that he |
| 8 |
could have been a bit more direct with his concern. Rather than |
| 9 |
stating that EXTRA_* does not exist as far as ebuilds go, he could |
| 10 |
have just stated that PMS does not allow these variables to be used by |
| 11 |
an ebuild. |
| 12 |
|
| 13 |
However, the reply to that email makes it clear that even though it |
| 14 |
was unstated Ciaran's meaning was understood. |
| 15 |
|
| 16 |
Sure, he didn't get into the why, but I'm not sure I'd expect that. |
| 17 |
I'd probably state it, but I'm probably the second-most-verbose person |
| 18 |
on this list. :) |
| 19 |
|
| 20 |
If somebody filed a bug against my package and pointed out that |
| 21 |
something was illegal per PMS, probably the first thing I'd do is read |
| 22 |
it to fully understand the situation, and then if I had a concern I'd |
| 23 |
probably ask via irc/private email/etc. That is as much to avoid |
| 24 |
making a fool out of myself in public, but also because when somebody |
| 25 |
who is obviously knowledgeable points out something they consider a |
| 26 |
flaw, it isn't a bad idea to give their concern full consideration. |
| 27 |
|
| 28 |
Sure, if PMS is wrong it ought to be fixed, but the whole point of |
| 29 |
having specifications is that you don't toss them the moment you don't |
| 30 |
like what they say. Then again, I work on regulated software in my |
| 31 |
real job, and even if the spec is wrong changing it still involves a |
| 32 |
process - you don't just ignore it (any behavior in violation of the |
| 33 |
spec is an automatic bug - even if the bug is to fix the spec - and |
| 34 |
unless pretty trivial is justification to prevent release (often this |
| 35 |
is done anyway since it is usually less work to just fix the problem |
| 36 |
than justify to the world not doing it)). |
| 37 |
|
| 38 |
In any case, it is best to not take these sorts of things personally |
| 39 |
all around. Most of us are here because our perverse tastes consider |
| 40 |
this stuff fun! :) Might as well keep it that way... |
| 41 |
|
| 42 |
Rich |
Archives