2004-04-05 - Summary of mozilla.org staff meeting
Gervase Markham
2004-04-05 - Summary of mozilla.org staff meeting
-------------------------------------------------
Present: bart, leaf, blizzard, chofmann, mitchell, myk, dbaron, scc,
gerv, ben.
*Mozilla 1.7 final*
- This will be the new stable branch
- Still talking 6/7 weeks and a couple of release candidates
- People are upset that the announcement wasn't made earlier
- That is, we didn't make official-sounding announcements in all the
right places
- We are apologising, and committing to doing better in the future
- Need to split the roadmap into two parts - soon and future - and get
the "soon" part out there
- We need to find a good balance between doing the basic research and
thinking, and communicating those things that have enough cohesion to
be beyond the squishy stage.
*Firefox 0.9*
- Extension Manager UI is now working
- For the server side, Ben is writing a Java web service based on
Tomcat, with MySQL back end
- DNS name will be update.mozilla.org
- Software update - notifications only - is on the plan for 1.0
- blake is working on an ActiveX control which runs in IE, to download
and install Firefox more smoothly
*Thunderbird 0.6*
- Pinstripe has landed; that was the last 0.6 feature
- 12-15 bugs on the list
*GRE*
- Still a very long term plan
- This is really a post-Firefox-1.0 thing
*Matters arising from the board meeting*
- Mozilla Foundation matters
- Mitchell focused on management cohesion of the Foundation
*Reorganising the newsgroup names*
- Still running on Netscape's news server
- There has always been a plan to move to our own hardware
- But this requires resources we don't have right now
- Need an experienced newsgroup admin to set them up on our new hardware
*Trademarks*
- Trademark policy document in the works
*Other*
- Looking at current support options - improvement, higher visibility
- Google Answers?
Gerv
Boris Zbarsky
> - People are upset that the announcement wasn't made earlier
> - That is, we didn't make official-sounding announcements in all the
> right places
Are you sure that's not "we didn't make any announcements in any of the
right places"? Because that's more what it was like...
> - We are apologising, and committing to doing better in the future
Permit me to be skeptical. I've seen all sorts of apologies and
commitments to do better on communication issues in this project; I have
seen very very few such commitments kept.
So I'll believe it when I see it. The next item is a good test of this
commitment, in fact.
> - Need to split the roadmap into two parts - soon and future - and get
> the "soon" part out there
If "soon" includes anything before the end of this year, I suggest this
be done ASAP. Today's a good day to do it, in fact....
-Boris
Michael Lefevre
[snip]
> - Need to split the roadmap into two parts - soon and future - and get
> the "soon" part out there
I hope this doesn't mean "put together a roadmap for the next 2 months
which everyone already knows about, and leave the future part for another
indeterminate of time, and publish it when it's no longer in the future".
The "soon" part was needed 6 months ago. The future part is needed soon.
Getting the soon part soon and the future part in the future is useless -
surely we're supposed to be following the roadmap, not mapping the route
already taken.
Splitting the roadmap into parts has been mentioned several times in the
past 6 months or so. The meeting minutes from last October 3rd, when
Brendan was just about to send out a draft...
--
Michael
Brendan Eich
> On 2004-04-22, Gervase Markham <ge...@mozilla.org> wrote:
> [snip]
>
>>- Need to split the roadmap into two parts - soon and future - and get
>> the "soon" part out there
Gerv didn't fix the meeting summary per mitchell's mail saying, in reply
to that "Need to split" item: "Not quite. I said that the roadmap had
already been organized this way, we had the place to put the 1.7 info
earlier, we just didn't do it."
This is a tempest in a teapot, but you raise some good points. I don't
have all the answers, or there *would* be a new roadmap up already.
Below I give my opinions, but much of what I write is tentative, and we
haven't gained agreement among drivers and others on the mundane stuff
sketched below. The more forward-looking technical ideas I'll leave for
a later post. The timeframe to get our story straight for the next year
or so is the next two months, maximum.
> I hope this doesn't mean "put together a roadmap for the next 2 months
> which everyone already knows about, and leave the future part for another
> indeterminate of time, and publish it when it's no longer in the future".
No, there's not going to be a futuristic roadmap; it would be useless,
akin to blogging (ahem) about the future, when food comes in pills and
cars fold into suitcases. Mozilla is about the next six months to a
year, and that's one roadmap, not two. But it takes time to get the
right plan together.
We still haven't retired SeaMonkey to a branch, which was last year's
plan. It wasn't the right plan, exactly, for that timeframe, although
we didn't know that until after it was "the plan". It was the right
plan in that Firefox is the future of the browser at mozilla.org, and
for many partners, some of whom can get us significant distribution
(fingers crossed).
The original roadmap update last April proposed to retire the suite in
one quarter-year milestone, which was not enough time. Ironically, when
hyatt and I wrote that update, we did not know that by July AOL would be
dropping the Netscape effort, leaving people out of work or looking for
jobs. All we knew was that we were facing cutbacks of some kind, and
that between the suite and the new apps, the better choice for any
future mozilla.org was the new apps.
Nor did we know that companies looking to upgrade from Netscape 4.x
would want the suite soon, last year and into this year. Such companies
generally contacted Netscape/AOL personell, not mozilla.org staff,
because mozilla.org was not its own legal entity, and we didn't get in
the loop until July.
So last year's roadmap, with a few adjustments, is still up, and still
not fully implemented, but we will be retiring the suite to a branch at
some point in the next year, in my judgment. After that point, we will
be making incompatible changes on the road to a Mozilla 2.0. There will
be a lot of 1.x compatibility, some of it optionally bundled with apps,
but not enough to carry the suite as well as the new apps.
> The "soon" part was needed 6 months ago.
The Mozilla Foundation was just getting staff rehired or transitioned
then, and Firefox was facing renaming (again) and trying to get a 1.0
schedule.
A top-down "general orders" roadmap would not have helped those efforts
-- we already had one that said "let's work on the new apps". People
who for whatever reason prefer SeaMonkey are not going to help, and were
not, and did not. What's more, SeaMonkey hackers may not do what the
Netscape 4.x customers want -- the hackers may wish to innovate in ways
that break "legacy" expectations.
So I think we had the "soon" part of the roadmap you say you wanted,
then. What more did you want?
> The future part is needed soon.
See http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/,
http://www.mozillazine.org/articles/article4584.html, and followups.
You've probably seen them, but without a roadmap, are they useless? I
think not, although some ideas (Eclipse-based IDE for XUL) went over
like lead balloons. Saying "Eclipse" gets some interest, but no one to
hack; a XUL IDE arguably would be better done on the Mozilla platform,
but we lack volunteers who can pull it off. This is just one example.
There is a lot going on behind the scenes, not all of it worth talking
about yet, and certainly not ready to road-map. But it might help to
know that we are working hard on requirements and plans for the future.
None of this should disrupt 1.7 or 1.8a, although 1.8 post-alpha, and
future milestones, may get a new schedule. More in a bit.
> Getting the soon part soon and the future part in the future is useless -
> surely we're supposed to be following the roadmap, not mapping the route
> already taken.
Right.
> Splitting the roadmap into parts has been mentioned several times in the
> past 6 months or so. The meeting minutes from last October 3rd, when
> Brendan was just about to send out a draft...
The revision happened without a split. The table-of-contents was added,
and the bit about dropping the suite was updated to talk about paying
customers keeping it alive, but only until the payments stop.
Volunteers may wish to carry the suite on a cvs trunk, based on the API
push to 2.0, after cvs.mozilla.org puts it on a branch. I don't see why
it should be on the trunk at cvs.mozilla.org, however. We won't be
closing the tree if the suite breaks, and we will break it sooner or
later, intentionally or not. We try not to host dead code. Volunteers
could keep it going at sourceforge, tracking API changes and so on.
Enough about the suite. The next roadmap update will posit successful,
continuously improving apps (Firefox 1.0, Thunderbird 1.0, others to be
announced), and will address platform issues as much as application
architecture. It will shake things up, which will require putting old
code on a branch for true sustaining engineering.
Mozilla 2.0 is the platform push (chewing bubblegum), with killer apps
(walking) something we continue to do well, as well. At least that's my
view.
I'll blog now, I promise.
/be
Michael Lefevre
> Michael Lefevre wrote:
>> On 2004-04-22, Gervase Markham <ge...@mozilla.org> wrote:
>> [snip]
>>
>>>- Need to split the roadmap into two parts - soon and future - and get
>>> the "soon" part out there
>
> Gerv didn't fix the meeting summary per mitchell's mail saying, in reply
> to that "Need to split" item: "Not quite. I said that the roadmap had
> already been organized this way, we had the place to put the 1.7 info
> earlier, we just didn't do it."
That does make more sense. Hopefully Alex (assuming it's him that does it)
will pick up that correction from here before that gets posted on
websites...
> Below I give my opinions, but much of what I write is tentative, and we
> haven't gained agreement among drivers and others on the mundane stuff
> sketched below.
If I may ask... why not? Have drivers been arguing about this stuff for
the past 3 (at least) months, or have people been doing other stuff
instead of reaching agreement, or something else?
> The timeframe to get our story straight for the next year or so is the
> next two months, maximum.
Sounds good.
>> I hope this doesn't mean "put together a roadmap for the next 2 months
>> which everyone already knows about, and leave the future part for another
>> indeterminate of time, and publish it when it's no longer in the future".
>
> No, there's not going to be a futuristic roadmap; it would be useless,
> akin to blogging (ahem) about the future, when food comes in pills and
> cars fold into suitcases.
By future, I was thinking of 4-12 months (i.e. beyond Mozilla 1.7 and
Firefox 1.0). And food pretty much comes in pills already, doesn't it?
> Mozilla is about the next six months to a
> year, and that's one roadmap, not two. But it takes time to get the
> right plan together.
It does take time, so one should ideally (not that many people do) start
the planning early enough to get to a plan before the period you're
planning for starts.
[snip some interesting stuff]
> So last year's roadmap, with a few adjustments, is still up, and still
> not fully implemented,
Not enough adjustments really - the broader stuff may not have been fully
implemented, but it still talks about 1.4 being the new stable branch, in
the future.
>> The "soon" part was needed 6 months ago.
>
> The Mozilla Foundation was just getting staff rehired or transitioned
> then, and Firefox was facing renaming (again) and trying to get a 1.0
> schedule.
>
> A top-down "general orders" roadmap would not have helped those efforts
> -- we already had one that said "let's work on the new apps". People
> who for whatever reason prefer SeaMonkey are not going to help, and were
> not, and did not. What's more, SeaMonkey hackers may not do what the
> Netscape 4.x customers want -- the hackers may wish to innovate in ways
> that break "legacy" expectations.
>
> So I think we had the "soon" part of the roadmap you say you wanted,
> then. What more did you want?
A roadmap which covered what you've just said in that paragraph. As you've
said, the previous roadmap was written before the layoffs and stuff
happened. Even if there weren't any major changes to the wider plan, the
roadmap should have been updated from being a proposal discussing 1.4 in
the future tense to acknowledge the fact that July had happened, 1.4 had
happened, Seamonkey wasn't going to be dead before 1.6, etc.
Maybe it didn't need anything huge - that's all the more reason why the
fix up that happened in January could have been done a couple of months or
more earlier. The document up there doesn't give the impression of "this
is the plan we're still following", it's more like "this is a proposal we
made last April and it's now totally redundant"
>> The future part is needed soon.
>
> See http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/,
> http://www.mozillazine.org/articles/article4584.html, and followups.
>
> You've probably seen them, but without a roadmap, are they useless?
I have seen them, but it shouldn't be necessary to be reading a bunch of
blogs, newsgroups and an independent(ish) news site in order to find
stuff. What would especially be useful is confirmation of which bits were
actual agreed plans, rather than just proposals and possibilities.
> There is a lot going on behind the scenes, not all of it worth talking
> about yet, and certainly not ready to road-map. But it might help to
> know that we are working hard on requirements and plans for the future.
It does help to know that. It would be better if it was obvious that there
was stuff going on.
> I'll blog now, I promise.
You could get a significant quantity of blog material from:
http://groups.google.com/groups?as_ugroup=netscape.public.mozilla.seamonkey&as_uauthors=brendan&as_qdr=m6
Thanks for the prompt response. If you have time to respond here, you
could be blogging :)
--
Michael
Brendan Eich
> Thanks for the prompt response. If you have time to respond here, you
> could be blogging :)
I'm working on a first entry right now, but it's tedious editing in a
textarea. Bite-sized blog entries tend to play sophomoric "gotcha"
games. Writing takes time, and news replies are faster, because shorter
and more disposable.
But http://weblogs.mozillazine.org/roadmap/ is coming -- stay tuned!
/be
mark kaplun
"Brendan Eich" <bre...@meer.net> wrote in message
news:40886829...@meer.net...
[snip]
> You've probably seen them, but without a roadmap, are they useless? I
> think not, although some ideas (Eclipse-based IDE for XUL) went over
> like lead balloons. Saying "Eclipse" gets some interest, but no one to
> hack; a XUL IDE arguably would be better done on the Mozilla platform,
> but we lack volunteers who can pull it off. This is just one example.
>
[snip]
> /be
AFAICT there were several attempts to develope a XUL IDE, so there is no
lack in volunteers. IMO the problem with those development attempts was that
people don't understand how much effort needs to be invested in order to
produce even a poor IDE. IMHO if there is a real interest in making this
happen, mozilla.org should nominate someone to drive this project to assure
proper planning and long time supervision. Once there is a driver, I think
that it will be easier to find volonteers.
[rant]
And what about the support for RTL languages in XUL? The tree widget is
unusable in RTL settings (can't find the exact bug), and there are other
problems with other widgets. So while mozilla is localized to heberw, the
localization itself is not as usable as mozilla in latin is (this is of
course not because of lack of effort of the localization team)
[/rant]
Mark.
Gervase Markham
>> - Need to split the roadmap into two parts - soon and future - and get
>> the "soon" part out there
>
> If "soon" includes anything before the end of this year, I suggest this
> be done ASAP. Today's a good day to do it, in fact....
Apologies - this was a mistranscription which Mitchell corrected in an
email to me, but I did not incorporate into the published version.
She said:
"Not quite. I said that the roadmap had already been organized this
way, we had the place to put the 1.7 info earlier, we just didn't do it."
Gerv
Brendan Eich
> "Brendan Eich" <bre...@meer.net> wrote in message
> news:40886829...@meer.net...
> [snip]
>
>>/be
>
>
> AFAICT there were several attempts to develope a XUL IDE, so there is no
> lack in volunteers. IMO the problem with those development attempts was that
> people don't understand how much effort needs to be invested in order to
> produce even a poor IDE.
... or as I put it, "we lack volunteers who can pull it off".
Good intentions are not enough. Driver-level support doesn't make a
given project (design, code, test, repeat) happen. I'm all for a XUL
IDE, and Ben has been for a while
(http://www.mozilla.org/projects/vixen/). Volunteers may not know how
much effort is required, but they have been scarce enough that they must
have an inkling, and not want to bite off more than they can chew.
> IMHO if there is a real interest in making this
> happen, mozilla.org should nominate someone to drive this project to assure
> proper planning and long time supervision. Once there is a driver, I think
> that it will be easier to find volonteers.
Ben's booked on fx0.9 and 1.0. He might be the best driver, certainly
after 1.0 -- or he might want to do the lead hacking himself, but this
gets back to my point about driving (Dilbert pointy-haired management)
being much less than what is needed: we need someone who shares the
vision and can actually do most of the hacking.
/be
KaiRo - Robert Kaiser
> that between the suite and the new apps, the better choice for any
> future mozilla.org was the new apps.
I still hope there's future for both... And I already know some people
who'd be willing to help developing Seamonkey into something that can
live in the new world (e.g. using new toolkit, and so on).
We still lack someone who can really drive such an effort, though...
If there would be a choice for poeple who want feature-parity in the new
apps with what we have in Seamonkey, that effort could be reconsidered,
but I still think thoughts behind the new apps are too different that we
could achieve that. I still believe there's a chance for us to modernize
Seamonkey under the hood in a way that it can cooperatively co-exist
with the new apps a long time, and that changes on both sides can be
easily ported to the other.
Robert Kaiser
Boris Zbarsky
> And what about the support for RTL languages in XUL? The tree widget is
> unusable in RTL settings (can't find the exact bug), and there are other
> problems with other widgets.
It doesn't help that XUL reflow is totally different from the way reflow works
in the rest of layout and that some XUL widgets do totally bizarre things in
general from a layout perspective (tree is particularly nasty this way). Add in
the fact that the XUL implementation is pretty much totally undocumented
(compare http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsIBox.h to
http://lxr.mozilla.org/seamonkey/source/layout/base/public/nsIFrame.h) and you
begin to see why most layout hackers just stay away from the XUL code.
Moving forward, we do need to solve the above problems (make HTML layout and XUL
layout not be quite so totally different, fix the documentation issues, etc).
But it'll take a lot of work....
-Boris
Smylers
> I'm working on a first entry right now, but it's tedious editing in a
> textarea.
Indeed -- I can very much recommend the 'Mozex' extension (despite its
being possibly the worst-named 'Mozilla' extension ever):
I've plugged gvim %t in for editing textareas, and now classify that as
one of the things I can't live without in a browser.
Smylers
Jan Varga
> [rant]
> And what about the support for RTL languages in XUL? The tree widget is
> unusable in RTL settings (can't find the exact bug), and there are other
> problems with other widgets. So while mozilla is localized to heberw, the
> localization itself is not as usable as mozilla in latin is (this is of
> course not because of lack of effort of the localization team)
> [/rant]
>
Sorry, that's my fault. Basic RTL support in trees was accidentally
removed as part of my checkin for bug 221619. I'll try to fix it ASAP.
However there are other issues which are probably more difficult to fix
like bug 176243 and 176244.
Jan
Willy Kreim
> and were not, and did not.
> continuously improving apps (Firefox 1.0, Thunderbird 1.0, others to be
> announced), and will address platform issues as much as application
> architecture. It will shake things up, which will require putting old
> code on a branch for true sustaining engineering.
>
> Mozilla 2.0 is the platform push (chewing bubblegum), with killer apps
> (walking) something we continue to do well, as well. At least that's my
> view.
I dare to disagree, strongly. At a time when Microsoft's sales speech
to customers against linux and Open Source is "we give you an
INTEGRATED SOLUTION, not a bunch of different programs tied together
with a piece of string" (hence they started talking about the
"Microsoft Office SYSTEM", and talk about Outlook and IE as part of
the "suite"), what do the bright guys at Mozilla.org do? Split the
apps!, Un-bundle, de-integration!. Great!!
What Mozilla.org should be doing is INTEGRATING MORE, with
OpenOffice.org, with GNOME, with KDE, with Java, with XMMS, with
everything else.
The success of Mozilla.org WON'T come by slowly taking 1, 2%, 5%, not
even 25% of the Windows Desktop browser market over a 5-year period...
but by evolving into a MORE INTEGRATED , CROSS-PLATFORM SUITE (more
than Mozilla 1.7 already is) that finally makes Linux (or freeBSD or
any other kernel you like to run under it, why not even PSX?, Sony
would be thrilled) an IRRESISTIBLE PROPOSITION OVER MICROSOFT OFFICE
AND MICROSOFT WINDOWS!.
Just my $.02
Willy
Jed
> I dare to disagree, strongly. At a time when Microsoft's sales speech
> to customers against linux and Open Source is "we give you an
> INTEGRATED SOLUTION, not a bunch of different programs tied together
> with a piece of string" (hence they started talking about the
> "Microsoft Office SYSTEM", and talk about Outlook and IE as part of
> the "suite"), what do the bright guys at Mozilla.org do? Split the
> apps!, Un-bundle, de-integration!. Great!!
>
> What Mozilla.org should be doing is INTEGRATING MORE, with
> OpenOffice.org, with GNOME, with KDE, with Java, with XMMS, with
> everything else.
>
> The success of Mozilla.org WON'T come by slowly taking 1, 2%, 5%, not
> even 25% of the Windows Desktop browser market over a 5-year period...
> but by evolving into a MORE INTEGRATED , CROSS-PLATFORM SUITE (more
> than Mozilla 1.7 already is) that finally makes Linux (or freeBSD or
> any other kernel you like to run under it, why not even PSX?, Sony
> would be thrilled) an IRRESISTIBLE PROPOSITION OVER MICROSOFT OFFICE
> AND MICROSOFT WINDOWS!.
>
> Just my $.02
> Willy
Ok, you have a point.
But why then is Firefox and Thunderbird so accepted by the public
unlike the suite? Why were their more downloads for Firefox then for
the latest suite release?
I agree with Brendan. The suite has corporate support behind it, and I
beleive that is do to it's integration. I think mozilla.org realizes
it, but they also know that to have a good suite, you need excelent
seperate apps that make this suite.
I can imagine in the future intergation will become a priority and you
will have something like the suite, but made up of these indivifual
apps (mozilla 2.0??)
I see no reason why Firefox/Thunderbird/Nvu/Sunbird could not be
integrated to work similarily to how the suite works now.
Boris Zbarsky
> What Mozilla.org should be doing is INTEGRATING MORE, with
> OpenOffice.org, with GNOME, with KDE, with Java, with XMMS, with
> everything else.
The suite design actually hurts such integration. Observe the patent inability
of the suite to launch the GNOME or KDE default mail client to handle email.
So argue for the suite if you will, but NOT on the basis that the suite makes it
easier to integrate with other software. It makes it harder.
-Boris
us...@domain.invalid
>
> I dare to disagree, strongly. At a time when Microsoft's sales speech
> to customers against linux and Open Source is "we give you an
> INTEGRATED SOLUTION, not a bunch of different programs tied together
> with a piece of string" (hence they started talking about the
> "Microsoft Office SYSTEM", and talk about Outlook and IE as part of
> the "suite"), what do the bright guys at Mozilla.org do? Split the
> apps!, Un-bundle, de-integration!. Great!!
>
> What Mozilla.org should be doing is INTEGRATING MORE, with
> OpenOffice.org, with GNOME, with KDE, with Java, with XMMS, with
> everything else.
>
> The success of Mozilla.org WON'T come by slowly taking 1, 2%, 5%, not
> even 25% of the Windows Desktop browser market over a 5-year period...
> but by evolving into a MORE INTEGRATED , CROSS-PLATFORM SUITE (more
> than Mozilla 1.7 already is) that finally makes Linux (or freeBSD or
> any other kernel you like to run under it, why not even PSX?, Sony
> would be thrilled) an IRRESISTIBLE PROPOSITION OVER MICROSOFT OFFICE
> AND MICROSOFT WINDOWS!.
>
> Just my $.02
> Willy
Microsoft does pretend to give integration and consistency when in fact
they do give mostly technology interlocking.
To my opinion proper interaction of components is good, interlocking is bad.
For a proper interaction of components the use of some open standards is
necessary. XUL can become such a standard if properly managed, and even
more if nativelly integrated in GNOME.
But I really hope noone will propose to follow the path of interlocking
while pretending to only want interaction of components. I want to have
choices, and interlocking removes such a thing.
So when speaking about integration, consistency and giving Microsoft as
an example, please relieve me of my doubts and confirm that you do not
promote interlocking in some way.
Thanks