What isn't planning.

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

What isn't planning.

SmoothPorcupine
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/2d0ae3c8e31a7b6f

To me, with the benefit of hindsight, it seems like a pretty severe
failure to plan, and the general attitude of everyone involved was to
put the cart before the horse. I'm interested in knowing what caused
this "culture" to arise and how I can recognize it, and, if possible,
prevent it, when it happens in front of/to me.


Also, if anyone would prefer I didn't cite it in my attempt to educate
others away from such practices, now would be a good time to say so.
_______________________________________________
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
I think the horrible, awful, sin committed by Mozilla here was caring more
about shipping modern features than keeping old numbers around.

If they're not careful, they will eventually run out!

(Why are we discussing this, anyhow?)

Wes

On 21 February 2012 11:22, SmoothPorcupine <[hidden email]>wrote:

>
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/2d0ae3c8e31a7b6f
>
> To me, with the benefit of hindsight, it seems like a pretty severe
> failure to plan, and the general attitude of everyone involved was to
> put the cart before the horse. I'm interested in knowing what caused
> this "culture" to arise and how I can recognize it, and, if possible,
> prevent it, when it happens in front of/to me.
>
>
> Also, if anyone would prefer I didn't cite it in my attempt to educate
> others away from such practices, now would be a good time to say so.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>



--
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.

Joshua Cranmer-2
In reply to this post by SmoothPorcupine
On 2/21/2012 10:22 AM, SmoothPorcupine wrote:

> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/2d0ae3c8e31a7b6f
>
> To me, with the benefit of hindsight, it seems like a pretty severe
> failure to plan, and the general attitude of everyone involved was to
> put the cart before the horse. I'm interested in knowing what caused
> this "culture" to arise and how I can recognize it, and, if possible,
> prevent it, when it happens in front of/to me.
>
>
> Also, if anyone would prefer I didn't cite it in my attempt to educate
> others away from such practices, now would be a good time to say so.
That thread occurred after the decision was effectively irrevocable, by
which point in time the discussion was moot--it wouldn't have achieved
anything to begin with, except perhaps educating the detractors of the
decision. Criticizing it for achieving nothing is pointless.
_______________________________________________
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.

Christopher Blizzard-2
In reply to this post by Wes Garland
On 2/21/2012 8:37 AM, Wes Garland wrote:
> (Why are we discussing this, anyhow?)

The real question is, why are you replying? :)

--Chris
_______________________________________________
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.

Jean-Marc Desperrier-2
In reply to this post by SmoothPorcupine
On 21/02/2012 17:37, Wes Garland wrote:
> I think the horrible, awful, sin committed by Mozilla here was caring more
> about shipping modern features than keeping old numbers around.

I think Mozilla should stop using number based version, and switch to
date based ones.

Using something like 2012ESR, 2012SR1 (standard release 1), 2012SR2
(standard release 2), etc. You would stop either at SR8 or SR9 each year
(6*8=48 weeks, 6*9=54 weeks).
_______________________________________________
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.

Cédric Corazza
Le 22/02/2012 00:30, Jean-Marc Desperrier a écrit :

> On 21/02/2012 17:37, Wes Garland wrote:
>> I think the horrible, awful, sin committed by Mozilla here was caring
>> more
>> about shipping modern features than keeping old numbers around.
>
> I think Mozilla should stop using number based version, and switch to
> date based ones.
>
> Using something like 2012ESR, 2012SR1 (standard release 1), 2012SR2
> (standard release 2), etc. You would stop either at SR8 or SR9 each year
> (6*8=48 weeks, 6*9=54 weeks).

Agreed. Soon or later, what would be the information carried by this
numbering. What does "Firefox 21" would mean?
This is really about marketing, and my guess is that this numbering
strategy will be changed soon.
My expectancy is that we (the Mozilla Project) won't wait or follow the
Google Chrome policy/strategy before moving on.
This has been certainly already discussed and argued in the thread about
numbering for the rapid release process, and will be soon again in our
plates because of the lack of information this carries for users.
Relying on date release, /à la/ Ubuntu, sounds much meaningful imo as we
release on a time-based schedule instead of a feature-based schedule.
Which would be YY.MM.x (YY for short year number, MM for month, and x
for security release --not part of Ubuntu numbering AFAIK).

Cédric
_______________________________________________
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.

Cédric Corazza

-- *x* not part of Ubuntu numbering AFAIK).
_______________________________________________
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 Cédric Corazza
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

--
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.

Christopher Blizzard-2
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.)

--Chris
_______________________________________________
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 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?

What I'm referring to is how people brought up legitimate problems in
that thread which were completely ignored at the time, but later
turned into a moderately sized user backlash when the news of it went
viral.

> (Why are we discussing this, anyhow?)

I figure there's a lesson to be learned here, even if that lesson
turns out to be, "Any criticism will always be taken personally."

This was really the only question that I never saw answered at the
time of the now invalid bug: How did this all happen? I get that the
discussions had already happened at the time, but the logic of those
discussions was never made apparent. All we were given was the
conclusion and multiple assurances that absolutely every aspect had
been taken into account already to reach that conclusion.

The most frustrating part of the whole ordeal, to me, was that it
seemed so hard to get an honest, straightforward answer. Virtually
every reply seemed like a dodge, not giving the full story, and
ultimately an attempt to keep face above all else. I'm pretty sure I
wasn't the only one that felt this 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.

Patrick Finch-2
In reply to this post by Cédric Corazza


On 2/22/2012 1:08 AM, Cédric Corazza wrote:

> Le 22/02/2012 00:30, Jean-Marc Desperrier a écrit :
>> On 21/02/2012 17:37, Wes Garland wrote:
>>> I think the horrible, awful, sin committed by Mozilla here was caring
>>> more
>>> about shipping modern features than keeping old numbers around.
>>
>> I think Mozilla should stop using number based version, and switch to
>> date based ones.
>>
>> Using something like 2012ESR, 2012SR1 (standard release 1), 2012SR2
>> (standard release 2), etc. You would stop either at SR8 or SR9 each year
>> (6*8=48 weeks, 6*9=54 weeks).
>
> Agreed. Soon or later, what would be the information carried by this
> numbering. What does "Firefox 21" would mean?
> This is really about marketing, and my guess is that this numbering
> strategy will be changed soon.

hey, if it was all about marketing, we'd get to 10 and then stop ;)

It isn't about marketing - we're working to make version numbers less
prominent (you will find little mention of them with a new stable
release).  Version numbers are for versioning, not for marketing.  There
are obvious challenges in de-emphasising versioning for client-side
software versus for hosted software, and we've hit and addressed many of
them in the past year.

I would expect marketing to talk to specific features and "the latest
version of Firefox".

So, what information is carried by "Firefox 21" to an
external-to-Mozilla audience (excluding the target audience for Firefox
ESR)?  Site compatibility would be my answer.  I think it's
developer-facing information, not user-facing.


Patrick







> My expectancy is that we (the Mozilla Project) won't wait or follow the
> Google Chrome policy/strategy before moving on.
> This has been certainly already discussed and argued in the thread about
> numbering for the rapid release process, and will be soon again in our
> plates because of the lack of information this carries for users.
> Relying on date release, /à la/ Ubuntu, sounds much meaningful imo as we
> release on a time-based schedule instead of a feature-based schedule.
> Which would be YY.MM.x (YY for short year number, MM for month, and x
> for security release --not part of Ubuntu numbering AFAIK).
>
> Cédric
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

--
Patrick Finch
Mozilla
[hidden email]
Mobile: +46 768 444 833
Office: +1 650 903 0800 ext. 340
Twitter: @patrickf
IM: [hidden email]
_______________________________________________
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 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.

I figure there's a lesson to be learned here, even if that lesson
> turns out to be, "Any criticism will always be taken personally."
>

Some group of users will always complain about change. News at 11.


> The most frustrating part of the whole ordeal, to me, was that it
> seemed so hard to get an honest, straightforward answer. Virtually
> every reply seemed like a dodge, not giving the full story, and
> ultimately an attempt to keep face above all else. I'm pretty sure I
> wasn't the only one that felt this way.
>

What's the big deal?  It's a number. I was kidding earlier when I suggested
there was a limited supply.

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.

Jean-Marc Desperrier-4
In reply to this post by Cédric Corazza
Patrick Finch a écrit :
> if it was all about marketing, we'd get to 10 and then stop ;)

Mine goes to 11
_______________________________________________
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.

Robert Kaiser
In reply to this post by SmoothPorcupine
Wes Garland schrieb:
> (Why are we discussing this, anyhow?)

Because everyone has different expectations how version numbers should
be created, and current software shows that.

MS Office is IIRC at 14 (though they left out 13 due to superstition).
Chrome is at 17. openSUSE at 12.1, Slackware has released 13.37 some
time ago.
X.org is at X11R6.7 server 1.11 (which is hard to understand, and even
the 11 in X11 is a version).
bind 9.8.0P4 and ghostscript 9.00 are in a similar range as the current
Firefox release, just like many other packages on my system.
libjpeg is at version 62.0.0, according to my package manager as of some
time ago, when I originally researched this. less is at 444, systemd as
very young software at 33, libiw at 30, emacs at 23.2, xterm at 271,
udev at 172. All of those are probably crazy, right?

xsane at 0.998 as quite old and long-time-stable project is probably
better, right? Just like kdiff3 0.9.95 or aspell 0.60.6, InkScape
0.48.2, elfutils 0.152, x264 0.116, PolicyKit 0.101 - all stable
versions of long-existing software.

And then of course TeX 3.1415926 - as their version asymptotically nears π.

Makes clear that version numbers are always following a specific "sane"
scheme, right?

I hope we can put this topic to rest.

Robert Kaiser

_______________________________________________
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 SmoothPorcupine
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

--
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.

Jim-267
On 02/22/2012 10:05 PM, Philip Chee wrote:
>> 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?

http://groups.google.com/group/mozilla.dev.planning/msg/fa27066fd6356f93
_______________________________________________
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.

Gijs Kruitbosch ("Hannibal")
In reply to this post by Philip Chee
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)

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

Hope that clarifies.

Gijs

* Robert Kaiser already cited numerous examples to the contrary, but for the
sake of the argument...
_______________________________________________
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 22, 4:01 am, Wes Garland <[hidden email]> wrote:
> Some group of users will always complain about change. News at 11.

See, that is what I would consider a dodge and a dismissal. I thought
it became clear previously that there are legitimate and far reaching
issues with hiding the version number in a non-standard place. Sure,
there will always be complaints about change, but there's a big
difference between personal preference and standards compliance.
There's also a reason why what goes viral goes viral.

> 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?

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!"

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. If for no other reason than to tell the
user the version they are running is not supported.

The only reasoning I can recall for hiding it that didn't seem like it
was some romanticism about having Firefox pretend to be something it
isn't was that it could confuse people. You'll have to forgive me if I
don't buy any other explanation than the primary reasoning for hiding
it being that it was considered an embarrassment. Especially since
that was the response whenever the rapid rate of major version number
bumping was brought up.

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. 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.

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. It's consolidation on a very specific use
case, throwing all others to the wind as if the difference between
supporting only the "average user" and supporting virtually anybody
were more than 100 lines of code in difference.

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 I really want to know is how it got to be like this. I'm not
interested in singling out one bad decision and the identities of the
people involved in making it. I want to know the process by which
decisions like this are made, because as far as I can tell, it looked
reasonable on the surface to the people involved at the time it was
made. 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.
_______________________________________________
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.

Gijs Kruitbosch ("Hannibal")
On 23/02/2012 10:21 AM, SmoothPorcupine wrote:
> What I really want to know is how it got to be like this. I'm not
> interested in singling out one bad decision and the identities of the
> people involved in making it. I want to know the process by which
> decisions like this are made, because as far as I can tell, it looked
> reasonable on the surface to the people involved at the time it was
> made. 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.

Great! I humbly direct you to this thread:

news://news.mozilla.org:119/[hidden email]

http://groups.google.com/group/mozilla.governance/browse_thread/thread/d9e3a7ab01f22529#

Cheers,
Gijs
_______________________________________________
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 Jim-267
On Thu, 23 Feb 2012 02:45:40 -0600, Jim wrote:
> On 02/22/2012 10:05 PM, Philip Chee wrote:
>>> 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?
>
> http://groups.google.com/group/mozilla.dev.planning/msg/fa27066fd6356f93

Quoting a random newsgroup posting doesn't answer my question. Try again?

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
12