1 |
On Fri, 11 Dec 2009 13:08:02 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> On Fri, Dec 11, 2009 at 08:57:22PM +0000, Ciaran McCreesh wrote: |
4 |
> > > Also, unless I'm on crack, the person leading PMS is fauli- I'd |
5 |
> > > expect he's the one who can pull the veto trick, not you. |
6 |
> > |
7 |
> > If *anyone* has any objections to patches, we resolve those |
8 |
> > objections before proceeding. |
9 |
> |
10 |
> Historically that has been a "do as I say, not as I do.". Via |
11 |
> ability to directly commit to pms, bits have gone in that would've |
12 |
> been argued- or, bits have been left out that would've made the |
13 |
> change in general a no go. |
14 |
|
15 |
Not since the Council agreed on PMS as a draft standard for EAPI 0 they |
16 |
haven't. |
17 |
|
18 |
> Unfortunately because of the way the rules are ran, once it's in all |
19 |
> it takes is one person stonewalling to keep from getting it fixed- |
20 |
> catch 22, if they can push it in then they get it via pulling a veto. |
21 |
|
22 |
Please point to any patch on the subject that has been sent to this list |
23 |
that has been rejected, by veto or any other means. |
24 |
|
25 |
> Further, frankly it provides a way for you to stonewall fixing known |
26 |
> flaws- the entire life of PMS you've been trying to force extended ~ |
27 |
> atom support and no one can get that bit removed because *you* |
28 |
> stonewall it. You wrote the original bits, now we can't fix the |
29 |
> things you forced in via this idiotic veto rule. |
30 |
|
31 |
Again, point to patches please. |
32 |
|
33 |
> I digress. Take it to the council as said, it would be interesting |
34 |
> to see the slap down on this one, and frankly PMS does need to be far |
35 |
> more democratic. Pointing at academic issues (1^23 chance is |
36 |
> academic, although yes, sorting it out for the academic case where |
37 |
> the FS supports NS is useful) as a claim that the majority cannot |
38 |
> overrule is plain political idiocy. |
39 |
|
40 |
The problem with writing code that sometimes doesn't work is that it |
41 |
sometimes doesn't work. And I've no idea what "1^23" is, but it doesn't |
42 |
look like the actual odds of it going wrong, which are around one in |
43 |
ten million per file, or one in a thousand on any given system, or a |
44 |
hundred affected systems once people start using newer filesystems. |
45 |
Hardly academic. |
46 |
|
47 |
If a democracy votes that it's ok to construct bridges out of materials |
48 |
that are known to cause random collapse one time in a thousand, would |
49 |
you consider those bridges to be well designed? |
50 |
|
51 |
> Either that or we just back off and let you get your way per the |
52 |
> norm. This I consider an untenuable solution if PMS is to have any |
53 |
> relevance long term. |
54 |
|
55 |
You still haven't explained what's wrong with doing a carefully phased |
56 |
withdrawal, rather than running around with an axe lopping bits out |
57 |
just because you can. |
58 |
|
59 |
-- |
60 |
Ciaran McCreesh |