What isn't planning.

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Philip Chee
On Thu, 23 Feb 2012 10:06:02 +0100, Gijs Kruitbosch wrote:

> On 23/02/2012 05:05 AM, Philip Chee wrote:
>> On Wed, 22 Feb 2012 07:01:34 -0500, Wes Garland wrote:
>>> On 21 February 2012 23:33, SmoothPorcupine<[hidden email]>wrote:
>>>
>>>> On Feb 21, 8:37 am, Wes Garland<[hidden email]>  wrote:
>>>>> caring more about shipping modern features than keeping old numbers
>>>> around.
>>>>
>>>> Was it strictly necessary to change the format of the version number
>>>> in order to ship modern features?
>>>>
>>>
>>> Yes. The old shipping schedule actually kept some features locked up for
>>> months -- sometimes more than a year -- after they were ready.
>>>
>>> The new shipping schedule -- ship what is finished when it is finished --
>>> is not compatible with a major/minor versioning scheme.
>>
>> And your evidence for this incompatibility is?
>>
>> Phil
>>
>
> I am not an expert, nor was I involved in this decision, but I can see a good
> reason: major/minor differences tend to* reflect differences in the 'magnitude'
> of changes shipped. In other words, does a new release only have security fixes,
> or 'minor' features, or 'major' features, UI overhaul, etc.
>
> In the "ship what's finished when it's finished" scenario, the version number of
> a release is fixed 3*n (where n is currently 6) weeks beforehand. Inbetween then
> and release, stuff gets put in/out, and it's virtually impossible to predict
> "how big" a release will be. You end up with the can of worms "we said we'd ship
> a major version now, but feature X isn't making it because of unexpected bugs"
> and then you want to postpone the release or you take X out and get negative PR
> / user feedback ("What's major about this version?! There's no / not enough big
> new feature(s)!").
>
> Optionally changing the version when you pull out features in Aurora/Beta, or
> only changing/fixing it to be 'major' later in the cycle, would result in hell
> for extensions, plugins and themes, confusion, and most annoyingly, similarly
> hairy debates. (see eg. the "Firefox 3.1 becoming 3.5" thread)

These are all perfectly fine justifications for going to an integer
release numbering, but none of these answer the question I asked.

> So, I sort of hoped this system would kill these debates. Look how that worked out!

> Hope that clarifies.

Unfortunately not. I don't see why you can't do all of the above with a
major.minor numbering scheme. Remember new features are not tied to a
particular release in the rapid release regime. Instead releases are
based on a clockwork schedule whether there are any new features or not.
So anything that applies to an integer numbering scheme, can equally
apply if you shift the decimal point one place to the left.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Wes Garland
In reply to this post by SmoothPorcupine
On 23 February 2012 04:21, SmoothPorcupine <[hidden email]>wrote:

> On Feb 22, 4:01 am, Wes Garland <[hidden email]> wrote:> What's the big
> deal?  It's a number.
>
> If the ever-increasing value of the major version number is truly
> trivial and not an embarrassment, why does it seem as if there was
> such a need to hide it?
>

People attach meaning to version numbers.  The new release scheme attaches
only the most trivial of meanings to version numbers: the bigger they get,
the newer the browser.

Personally, I think end users should care not one bit about version
numbers. They should just care that they have the latest Firefox.  What's
so hard about that?

After the decision was made, it seems like every time the topic was
> brought up, the general solution was, "We don't need version numbers!
> We can hide it! We wont support anything but the current version!
> Enterprise is not supported!"
>

I'll remember to tell the guys doing the ESR that The Enterprise is not
supported on the next Enterprise Working Group conference call. It will
save everybody a lot of time!

By the way, version numbers have nothing to do with the Enterprise, either.

All four of which seem incredibly naive to me. Version numbers are
> needed because Firefox wont be able enforce updates on every computer
> on which it is installed through general network failure, explicit DNS
> or IP address blocking, read only root or /usr filesystems, lack of
> root access, or any number of existing or future problems that can and
> most certainly will ensure that not all computers attempting to run
> Firefox will be up to date.


So, you want to devise a system by which Mozilla encourages people to run
browsers with known security vulnerabilities, and you are championing this
as a good thing? Are you a malware author?


> If for no other reason than to tell the
> user the version they are running is not supported.
>

What does that have to with a number?

By the way, do you know what version webkit is at right now?  Mid-500s if I
remember correctly.


> I can understand the difficulty with supporting 10 different versions
> of Firefox with any number of arbitrary changes to any subsystem back
> and forth between versions. But to simply refuse to, or to plan to
> refuse to, is the opposite of progress.


Okay, please clarify how supporting 9 out of date browser revisions is
progress.


> It's not like the old routines
> stopped working for the versions they worked for, unless, I dunno, the
> support guides were written in a style of HTML that modern browsers
> don't render usably anymore.
>

I don't understand this paragraph.  Do you really believe that supporting a
browser involves writing support guides?

Given that forced updates are about the only reason Firefox became
> ineligible for enterprise use, I can hardly see what's happened to
> Firefox as forward movement.


This has nothing to do with it. An enterprise that wants a non-standard
configuration of Firefox should ...... *drum roll* ........ install a
non-standard configuration of Firefox.

An enterprise that wants a six-month-old version of Firefox with known
security holes can install that, too.

Heck, an enterprise that wants a long-term supported Firefox can install
the Extended Support Release.  If they pick that one, they'll only get new
features a few times a year, but they will be up to date on security
patches.


> If failure to link on certain platforms isn't an indication of toxic
> levels of failure to maintain internal modularity, I don't know what
> is.
>

What are you talking about? On what supported platforms does the browser
not link?  Are you trying to mix and match components from one browser
version to another? Why would you do that?


> I'm not interested in reviving the debate or trying to change
> the direction Firefox is going or any other manner of dead horse
> beating, I simply want to know what happened, regardless of whether
> any one person thinks the decision was a good one or not.
>
>
I don't believe this is true.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Jonathan Kew-3
In reply to this post by Philip Chee
On 23 Feb 2012, at 12:37, Philip Chee wrote:
>
> Unfortunately not. I don't see why you can't do all of the above with a
> major.minor numbering scheme. Remember new features are not tied to a
> particular release in the rapid release regime. Instead releases are
> based on a clockwork schedule whether there are any new features or not.
> So anything that applies to an integer numbering scheme, can equally
> apply if you shift the decimal point one place to the left.

I'm hesitant to butt in here, on a topic that's been so thoroughly rehashed already, but I guess I'll give it a try....

If you move the decimal point, you make every 10th one of these clockwork-scheduled releases appear to be "major", and the intervening 9 releases "minor".

That creates an expectation that every 10th release involves changes of a somehow different nature than the changes that go into other releases - which is exactly counter to the expectations of the rapid release model.

If we used what you refer to as "major.minor" numbering together with the rapid release regime, we'd either create a _false_ expectation of "major" changes every 60 weeks, and "minor" ones in between, which would bear no relation to the kinds of changes that actually happen in any given release; or we'd have to hold back major features until we hit the next x.0 number and/or hold back x.0 releases while waiting for major features to be ready - exactly the problems we wanted to resolve by going to this release model.

I don't know how to make it any clearer than that.

JK

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Philip Chee
In reply to this post by Philip Chee
On Thu, 23 Feb 2012 12:53:47 +0000, Jonathan Kew wrote:

> On 23 Feb 2012, at 12:37, Philip Chee wrote:
>>
>> Unfortunately not. I don't see why you can't do all of the above
>> with a major.minor numbering scheme. Remember new features are not
>> tied to a particular release in the rapid release regime. Instead
>> releases are based on a clockwork schedule whether there are any
>> new features or not. So anything that applies to an integer
>> numbering scheme, can equally apply if you shift the decimal point
>> one place to the left.
>
> I'm hesitant to butt in here, on a topic that's been so thoroughly
> rehashed already, but I guess I'll give it a try....
>
> If you move the decimal point, you make every 10th one of these
> clockwork-scheduled releases appear to be "major", and the
> intervening 9 releases "minor".
>
> That creates an expectation that every 10th release involves changes
> of a somehow different nature than the changes that go into other
> releases - which is exactly counter to the expectations of the rapid
> release model.

> If we used what you refer to as "major.minor" numbering together with
> the rapid release regime, we'd either create a _false_ expectation of
> "major" changes every 60 weeks, and "minor" ones in between, which
> would bear no relation to the kinds of changes that actually happen
> in any given release; or we'd have to hold back major features until
> we hit the next x.0 number and/or hold back x.0 releases while
> waiting for major features to be ready - exactly the problems we
> wanted to resolve by going to this release model.

But "numbers don't mean anything" in the new regime. So there are no
false expectations with the usual clockwork increment of 4.9 -> 5.0 (an
increment of 0.1 as usual). Remember that users would have had 9
releases to get used to this sort of regular tick-tock increments.

> I don't know how to make it any clearer than that.

Why can't Firefox do what we did with SeaMonkey?

2.6 -> 2.7 -> 2.8 -> 2.9 -> 2.10 (and presumably 2.11 onwards).
Presumably we'll go to 3.0 eventually when we have accumulated
sufficient new features to warrant such a bump.

And indeed our experience is that our user base had no difficulty
adjusting to this (except for some excitement and wagering if we were
going to 2.10 or 3.0)

In addition we have seen a significant uptick in ADUs since moving to
the rapid release cycle so any confusion caused by us sticking to
major.minor versioning appears to have little or no impact. It might
even have provided some psychological reassurance that the SeaMonkey
developers hadn't suddenly gone off the rails with this rapid release
malarkey.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Steve Wendt
On 2/23/2012 10:13 AM, Philip Chee wrote:

> And indeed our experience is that our user base had no difficulty
> adjusting to this

+1

> even have provided some psychological reassurance that the SeaMonkey
> developers hadn't suddenly gone off the rails with this rapid release
> malarkey.

+1
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Alexander Keybl
In reply to this post by Philip Chee
>>> Instead
>>> releases are based on a clockwork schedule whether there are any
>>> new features or not. So anything that applies to an integer
>>> numbering scheme, can equally apply if you shift the decimal point
>>> one place to the left.

> Why can't Firefox do what we did with SeaMonkey?

Hi Phil and all,

Please see my previous reply to a very similar discussion here: https://lists.mozilla.org/newsportal/article.php?id=19261&group=mozilla.dev.planning

We appreciate the feedback, though we've heard these suggestions prior and made the decision to move forward with integer versioning (as opposed to major/minor versioning or date versioning) after having weighed the pros/cons of each option.

-Alex

On Feb 23, 2012, at 10:13 AM, Philip Chee wrote:

> On Thu, 23 Feb 2012 12:53:47 +0000, Jonathan Kew wrote:
>> On 23 Feb 2012, at 12:37, Philip Chee wrote:
>>>
>>> Unfortunately not. I don't see why you can't do all of the above
>>> with a major.minor numbering scheme. Remember new features are not
>>> tied to a particular release in the rapid release regime. Instead
>>> releases are based on a clockwork schedule whether there are any
>>> new features or not. So anything that applies to an integer
>>> numbering scheme, can equally apply if you shift the decimal point
>>> one place to the left.
>>
>> I'm hesitant to butt in here, on a topic that's been so thoroughly
>> rehashed already, but I guess I'll give it a try....
>>
>> If you move the decimal point, you make every 10th one of these
>> clockwork-scheduled releases appear to be "major", and the
>> intervening 9 releases "minor".
>>
>> That creates an expectation that every 10th release involves changes
>> of a somehow different nature than the changes that go into other
>> releases - which is exactly counter to the expectations of the rapid
>> release model.
>
>> If we used what you refer to as "major.minor" numbering together with
>> the rapid release regime, we'd either create a _false_ expectation of
>> "major" changes every 60 weeks, and "minor" ones in between, which
>> would bear no relation to the kinds of changes that actually happen
>> in any given release; or we'd have to hold back major features until
>> we hit the next x.0 number and/or hold back x.0 releases while
>> waiting for major features to be ready - exactly the problems we
>> wanted to resolve by going to this release model.
>
> But "numbers don't mean anything" in the new regime. So there are no
> false expectations with the usual clockwork increment of 4.9 -> 5.0 (an
> increment of 0.1 as usual). Remember that users would have had 9
> releases to get used to this sort of regular tick-tock increments.
>
>> I don't know how to make it any clearer than that.
>
> Why can't Firefox do what we did with SeaMonkey?
>
> 2.6 -> 2.7 -> 2.8 -> 2.9 -> 2.10 (and presumably 2.11 onwards).
> Presumably we'll go to 3.0 eventually when we have accumulated
> sufficient new features to warrant such a bump.
>
> And indeed our experience is that our user base had no difficulty
> adjusting to this (except for some excitement and wagering if we were
> going to 2.10 or 3.0)
>
> In addition we have seen a significant uptick in ADUs since moving to
> the rapid release cycle so any confusion caused by us sticking to
> major.minor versioning appears to have little or no impact. It might
> even have provided some psychological reassurance that the SeaMonkey
> developers hadn't suddenly gone off the rails with this rapid release
> malarkey.
>
> Phil
>
> --
> Philip Chee <[hidden email]>, <[hidden email]>
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

SmoothPorcupine
In reply to this post by SmoothPorcupine
On Feb 23, 4:42 am, Wes Garland <[hidden email]> wrote:
> So, you want to devise a system by which Mozilla encourages people to run
> browsers with known security vulnerabilities?

No. I'm saying out of date software is an inevitability that should be
accounted for. Acceptance of this does not imply endorsement of this.
It is physically possible to have tech support first inform the user
that they /should/ install the latest version if they are running an
old version. They can literally say, "Support for that version is
being dropped."

> Please clarify how supporting 9 out of date browser revisions is progress.

It's not progress, it's simply maintenance.

> > I'm not interested in reviving the debate or trying to change
> > the direction Firefox is going or any other manner of dead horse
> > beating, I simply want to know what happened, regardless of whether
> > any one person thinks the decision was a good one or not.
>
> I don't believe this is true.

Then what do you think is my actual aim?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

SmoothPorcupine
In reply to this post by Steve Wendt
On Feb 23, 11:02 am, Steve Wendt <[hidden email]> wrote:
> On 2/23/2012 10:13 AM, Philip Chee wrote:
> > even have provided some psychological reassurance that the SeaMonkey
> > developers hadn't suddenly gone off the rails with this rapid release
> > malarkey.
>
> +1

I... I did feel that way. <_<
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Joe Drew-5
In reply to this post by Christopher Blizzard-2
On 2012-02-21 8:31 PM, Christopher Blizzard wrote:

> On 2/21/2012 4:48 PM, Wes Garland wrote:
>> 2012/2/21 Cédric Corazza<[hidden email]>
>>
>>> What does "Firefox 21" would mean?
>>>
>> It means that it is newer than Firefox 20 and older than Firefox 22.
>>
>> Wes
>>
>
> And?  Drinkin' time.  (At least in the en-US builds.)

Yet *another* reason we need en_CA. Are you listening, Mike Beltzner????

joe
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Jeff Walden-2
In reply to this post by SmoothPorcupine
On 02/23/2012 04:42 AM, Wes Garland wrote:
> So, you want to devise a system by which Mozilla encourages people to run
> browsers with known security vulnerabilities, and you are championing this
> as a good thing? Are you a malware author?

Wes, this is probably crossing a line just a little bit, at least not without a :-) or something.  I know you're not being serious...but even still.

(Which is not to say that I don't find your phrasing kinda funny.  :-)  But it seems subject to misunderstanding as you've written it, and it unnecessarily distracts from your point that such a system produces incentives to use an insecure browser.)

Jeff
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Justin Wood (Callek)-2
In reply to this post by Philip Chee
Alex Keybl wrote:

>>>> Instead
>>>> releases are based on a clockwork schedule whether there are any
>>>> new features or not. So anything that applies to an integer
>>>> numbering scheme, can equally apply if you shift the decimal point
>>>> one place to the left.
>
>> Why can't Firefox do what we did with SeaMonkey?
>
> Hi Phil and all,
>
> Please see my previous reply to a very similar discussion here: https://lists.mozilla.org/newsportal/article.php?id=19261&group=mozilla.dev.planning
>
> We appreciate the feedback, though we've heard these suggestions prior and made the decision to move forward with integer versioning (as opposed to major/minor versioning or date versioning) after having weighed the pros/cons of each option.
>

And I don't mind saying on the record, that I do feel (given the same
justifications of Firefox) that I do feel the integer rather than
major/minor versioning would have/would be better for SeaMonkey as well
-- if we feel willing to deal with a bunch of vociferous users with
similar thread to this.

But others in SeaMonkey leadership do not wish to do that, so I choose
not to argue and instead spend my energy making SeaMonkey better, since
"versions don't matter" :-)

--
~Justin Wood (Callek)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

SmoothPorcupine
On Feb 25, 11:29 pm, "Justin Wood (Callek)" <[hidden email]> wrote:
> I choose not to argue and instead spend my energy making SeaMonkey better

And that kind of attitude is why I'm a proud SeaMonkey user. :D
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Ryan VanderMeulen
On 2/26/2012 4:40 AM, SmoothPorcupine wrote:
> On Feb 25, 11:29 pm, "Justin Wood (Callek)"<[hidden email]>  wrote:
>> I choose not to argue and instead spend my energy making SeaMonkey better
>
> And that kind of attitude is why I'm a proud SeaMonkey user. :D

That attitude is prevalent amongst Firefox developers too, FWIW. Hence
why most of them are sick to death of this being brought up again and
again and again and again...
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

SmoothPorcupine
On Feb 26, 11:30 am, Ryan VanderMeulen <[hidden email]> wrote:
> Most of them are sick to death of this being brought up again and
> again and again and again...

Yes, I should have known better than to consider the mere possibility
that there was some way to approach the subject to ask the question I
wanted to ask that wouldn't have resulted in the itching of sore
wounds.

And now I /do/ know better.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

Ryan VanderMeulen
On 2/27/2012 3:17 PM, SmoothPorcupine wrote:
> Yes, I should have known better than to consider the mere possibility
> that there was some way to approach the subject to ask the question I
> wanted to ask that wouldn't have resulted in the itching of sore
> wounds.
>
> And now I /do/ know better.

You asked a question on a topic that's been asked repeatedly about now
for almost a year. In these newsgroups. On the Mozilla blogs. On
Slashdot. On Reddit. Etc etc etc. Everything that's been said in this
thread has been said before.

Don't act like a martyr because you felt like stirring the pot rather
than reading the past conversations and then asking your question if
there really was something left unanswered. Honestly, don't you see the
irony in the fact that you profess to like that SM developers would
rather develop than bikeshed in a thread you started about version
number bikeshedding???

I'm not denying that mistakes were made in how the new versioning plan
was communicated (nor have I seen anyone from Mozilla say otherwise).
The addon strategy could probably have stood to have been better fleshed
out than it was. The Enterprise situation wasn't as well-understood as
it probably should have been. Everyone gets that. Mistakes were made and
it's rather obvious that Mozilla has been working hard to learn from
them and correct them (see ESR releases, default addon compatibility,
and so forth). But to keep beating a dead horse about a decision that's
been made and isn't going to change is completely non-productive and
diverting Mozilla developers from productive work.

Note that I'm a community member as much as you are. Obviously opinions
are diverse. Obviously you disagree with the decision they made. That's
fine and you're certainly entitled to. But using it to cop a "Mozilla
doesn't care" attitude is a bit daffy in my opinion.

-Ryan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What isn't planning.

SmoothPorcupine
On Feb 27, 2:50 pm, Ryan VanderMeulen <[hidden email]> wrote:
> You asked a question on a topic that's been asked repeatedly about now
> for almost a year.

My intent was to only ask a question that wasn't answered. It appears
the answer is, "Mozilla governance is a mess and most of us don't even
know how it happened." Unless the right person comes along and, by
some miracle, answers the question that I /did/ ask, I have no reason
to respond other than to clarify what I intended to ask to begin with.

> a thread you started about version number bikeshedding???

I don't care about version numbers. If I did, I would have said
something to that effect by now. You'll have to forgive me if I don't
see where I said something I never intended to say.

> Obviously you disagree with the decision they made.

Honestly, I went in neutral and came out concluding the decision was
fine. In context, obviously. I still maintain the #cat-v perspective
that the actual user-facing design decisions are "usability"
nightmares that allow end users to slip even further into ignorance,
opening up unimaginably catastrophic security holes in places you /
can't/ patch, and that the very design process is and always has been
severely broken. I could fill page after page with actual criticisms
that, if actually taken seriously, would actually make Firefox (and,
by extension, SeaMonkey) better. But a prerequisite to people taking
what you say seriously is that they're convinced you're a rational
person to begin with, so I'll save that for some other decade.

It's not the attempt to hide version numbers that I disagree with so
much as how the arguments against doing so were taken. That is, it
took a crowd to point out how bad on an idea it was. My interest is in
learning how it was so easy to dismiss individual arguments early on
in the process but somehow easier to accept them when "the version
numbers issue" bubble finally popped and everyone jumped in to rant
about how much they disagreed with everything Firefox had been doing
since the advent of the rapid release schedule and that callously
violating this one small standard with such far-reaching implications
was the last straw.

> a "Mozilla doesn't care" attitude

It's not out of apathy that I don't expect a response. There are very
few people in this world that will admit to a personal fault before
faulting "the system" they're a member of a thousand times. Either
there's someone with the necessary memory of events, introspective
capabilities, motivation to reply, and free time who will see this
thread or there isn't.

In the meantime, I guess we can see how well meta arguments can be
used to defend oneself against accusations of trolling. If that
doesn't work, my conclusion is that the label attaches itself to the
back of the spine at about armpit level.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12