Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields

[Gervase Markham]

J. Paul Reed wrote:

> Which leads me to believe you're not seeing the same thing I'm seeing when
> I load that URL (which is why I wish we were using Mailman instead of
> Majordomo, but that's an ancillary issue).

Don't blame Majordomo, blame me (see below.)

> You did suggest "the first one" (84876), as you did this time, but then
> concede "I guess perf is more important right now," leading me to believe
> you think 124174 should be fixed first.
>
> So, I reiterate: which is it?

Oops, sorry. I let me recollection of that email thread overrule the 
evidence of my own eyes. I remember wanting 84876 to be fixed first; I 
failed to notice that I'd conceded (at the time) that the other was more 
important.

However, the situation is now different - the big need for perf was for 
the b.m.o. upgrade, which has now happened. So perf has got less 
important. And I was willing to let 84876 go for a bit because I thought 
you would be tackling both of them in a reasonably short timeframe. But 
that hasn't happened.

So, my view has changed in the past month, as circumstances have 
changed. I apologise if this change has caused you inconvenience, and 
(relating to the above discussion) I apologise for not reading carefully 
enough first time.

> >In other words, it gives our customers a false sense of when they are
> >going to get what they want. I thought that sort of thing was reserved
> >for commercial projects :-)
>
> Actually, that's not true.

Well, you were the one who used the words "give the illusion that".

> >But, at the risk of engendering controversy, if you won't have time for
> >the other bug, I'm happy to produce a patch and drive it through. I
> >conceded after our technical disagreement on that bug, partly on the
> >basis that some fix was better than no fix (as several people said.) But
> >having done that, we still have no fix...
>
> We have no fix because every time you get involved on 84876, it turns 
> into a
> pissing match. That's not assigning blame to you (if anything, I'm as
> responsible as you are), but it *is* a statement of fact.

As you imply above, it takes two to have an argument.

> If you remember, I wanted to get 84876 fixed in August, *before* school
> started, when I had a bunch of time. I made this very clear at the time.
> That didn't happen because the time was basically spent arguing between
> ourselves, then arguing in front of justdave, and then it was September.

I think that it's important that Bugzilla developers should feel free to 
challenge the implementation of a feature if they don't think it's right 
technically. That's what review (and design, which we don't do enough 
of) is all about.

I think that the blame for the 84876 debacle can be shared approximately 
equally between you, me and Dave - you and I for a complete inability to 
see the other side of the argument, and Dave for sitting on the problem 
and not making a decision for a long time when asked to do so. But I 
think we should leave that behind and try and work out the best way to 
move forward.

> At that time, bbaetz contributed some other code to help with 84876, and I
> said I'd merge everyone's patches together and submit something. I still
> plan on doing so, and I told you the timetable in which I plan on 
> doing it.
>
> Considering that the holidays are coming up and 84876 is a big bug
> involving not only fixing the bug itself, but the associated email
> templatization and this isn't affecting anyone in a superbad way (i.e.
> we're not in the 2.18--or 2.17.2--push right now), I think it can wait 
> for a month.

I would hope to get the templatisation project finished well before the 
next release push, because the localised version translators need a good 
bit of lead time to get their versions sorted out. l10n patches are not 
like others, which can be checked in five minutes before a freeze. And 
we have been waiting nearly two months already.

I understand that you have other commitments; that's why I am suggesting 
you let someone else with more time take on one or more of these patches.

Gerv