Minutes of mozilla.org staff meeting - 2003-01-29
Gervase Markham
-----------------------------------
Present: Scott, Dawn, Gerv, Leaf, Dan, Seth, Marcia, Myk, Asa and Mitchell.
(Brendan returns from holiday on the 5th of February.)
*Direction of the Project*
- Drivers say: time to clean up recently-landed features
- Discussed progress of GRE and Phoenix projects
*Communications*
- It would be good for staff to communicate better
- We agreed to post minutes of the weekly meetings to the newsgroups,
as far as what is discussed can be made public (and here they are :-)
*Project Status*
- We'd like to get input on the roadmap for the different parts of
Mozilla from those actually working on the code
- Begin with a "past, present and future" summary from each project
- What's happened since 1.0
- Where we are now
- Where we think we are going
- Seth emailing module owners and compiling their responses.
*Are we a Distribution?*
There was a discussion about how much mozilla.org is de facto a
distribution, and whether we want to be in the distribution business.
This has to be considered in relation to the fact that if big changes
are made, a release may not necessarily be better than the previous one.
There was also a discussion of whether each and every milestone needs to
be a better user experience than the previous one, and if so, how to
accomplish significant changes. We also talked about whether the the
needs of Mozilla end users varies from that of Mozilla developers in
this regard.
*Chimera 0.7 Release*
We want to do this soon, but need to figure out whether there is a
problem with using the chimera name. Mitchell suggested we ship with
C***** as an interim measure if necessary. Asa to contact chimera.org
*Mozdev Donation Drive*
- Dawn to put news item on the front page.
Boris Zbarsky
> *Are we a Distribution?*
>
> There was a discussion about how much mozilla.org is de facto a
> distribution, and whether we want to be in the distribution business.
> This has to be considered in relation to the fact that if big changes
> are made, a release may not necessarily be better than the previous one.
>
> There was also a discussion of whether each and every milestone needs to
> be a better user experience than the previous one, and if so, how to
> accomplish significant changes. We also talked about whether the the
> needs of Mozilla end users varies from that of Mozilla developers in
> this regard.
Imo, this is one of the most pressing issues we are facing... One
interesting suggestion I've seen was to split up totally back end
development (eg layout, content, necko) and front end development.
Builds that ship would ship off of stable tags of the back end and with
whatever front end features got added. The back end could be worked on
without fear of having to make sure that three weeks from now things are
in shape to ship (there are some changes that we're looking at that
would need a lot more time than that, with concerted effort from
multiple developers... I suppose we could just branch all of layout/,
but....)
> - We'd like to get input on the roadmap for the different parts of
> Mozilla from those actually working on the code
What sorts of input are you looking for exactly?
Christian Biesinger
> Minutes of Staff Meeting 2003-01-29
Firstly, thanks for making this public!
> - It would be good for staff to communicate better
> - We agreed to post minutes of the weekly meetings to the newsgroups,
> as far as what is discussed can be made public (and here they are :-)
This makes me wonder what secret stuff staff is discussing... guess you
wouldn't tell me, because then it wouldn't be anymore secret, but I'd
really like to know that.
> - We'd like to get input on the roadmap for the different parts of
> Mozilla from those actually working on the code
Roadmap as in roadmap.html? my input it, the freezes are too long :)
> *Are we a Distribution?*
Well, this question is answered by the removal of Debug and QA menus
already.
Michael Lefevre
wrote:
> Gervase Markham wrote:
>> Minutes of Staff Meeting 2003-01-29
>
> Firstly, thanks for making this public!
hear, hear! :) although it can be a pain in the behind to make it
happen, communication is really important...
>> - It would be good for staff to communicate better
>> - We agreed to post minutes of the weekly meetings to the newsgroups,
>> as far as what is discussed can be made public (and here they are
>> :-)
>
> This makes me wonder what secret stuff staff is discussing... guess you
> wouldn't tell me, because then it wouldn't be anymore secret, but I'd
> really like to know that.
well obviously I have no idea what happens in the mozilla meetings, but
guessing from other organisations I know that have private bits of their
minutes, they aren't very interesting when you do get to see them. They
tend to be internal issues involving staff/individuals (staff holidays,
staff leaving, joining), or other entities (e.g. relationships with
other companies/organisations).
[snip]
>> *Are we a Distribution?*
>
> Well, this question is answered by the removal of Debug and QA menus
> already.
well yes, but they didn't (I hope!) have a long discussion about whether
they had been distributing mozilla binaries - as you say, the answer to
that is obvious. As the paragraph in the minutes says, the issues are
more about "how much should we be distribution". Just because they've
been releasing binaries without Debug/QA menus so far, doesn't mean they
have to carry on. Equally they could go further down the distribution
path than just releasing those binaries for "testing".
But I guess if they're going to post minutes here, they need to be more
precise with their agenda item titles... :)
--
Michael
Gervase Markham
> > Mozilla from those actually working on the code
>
> What sorts of input are you looking for exactly?
What people's plans are for their modules.
For example, it's no secret that the layout guys want to do some fairly
serious architectural work as soon as possible (which raises questions
about how we manage that if we stick to the current 5-week cycle.) On
the other hand, there's a point of view that says that the Mozilla
application (in terms of UI and feature count) is fairly complete, and
there should be a bug-fixing period. Which raises different questions
about cycles. So we want to hear the views of people at the sharp end on
what they want to do with the code in the next six months.
Gerv
Arron
>-----------------------------------
>- Drivers say: time to clean up recently-landed features
>- Discussed progress of GRE and Phoenix projects
Just recently landed features? There's been a lot of talk by the
developers and users about feature freezing and code cleanup. Obviously
with Mozilla being Open Source, you can't control what people want to work
on, but as authority figures, you could certainly devise plans to lead
people into that direction.
And by 'a lot of talk', I mean it's mentioned at least a couple of times a
week for the last 6 months (probably more, but my memory is bad).
>*Communications*
>- It would be good for staff to communicate better
>- We agreed to post minutes of the weekly meetings to the newsgroups,
> as far as what is discussed can be made public (and here they are :-)
More comminucation is always better. :)
It would be nice to have the module owners page up-to-date. Everyone knows
of Black Wednesday, and almost everyone knows who got fired or re-assigned,
yet those people still sit on the module owners page. I know you change
the list when people provide new information, however, perhaps a more
proactive role would be better.
And since I'm on the topic of module owners, there has also been a lot of
talk about many module owners not really caring about their modules any
more, or being too busy with other things. I've personally given up on MO.
Sure, I'll CC them on a bug if it changes something in their module, but if
they don't comment, I just pretend they are okay with it.
>- We'd like to get input on the roadmap for the different parts of
> Mozilla from those actually working on the code
Longer Alpha Phase, Shorter Beta Phase, and a much shorter (or at least
less delayed) tree frozen stage seems to be the general concensus.
My twist on it is here:
http://mozilla.animecity.nu/mybranching.png
(compare it to http://www.mozilla.org/roadmap/branching-2002-12-26.png
which is what I hacked ;) )
a) 2 Month Alpha Phase, where anything with a r/sr goes
b) One week freeze while things become stable enough for an alpha release
(as per usual, a= required on checkins, and checkins should be only
blockers, no new features or structural rewrites)
c) Two week beta, where only bug fixe checkins are allowed. This would be
controlled by SRs (or possibly drivers if they feel the need), and no new
features or structure changes could be added at this time. Basically, a
little more lenient than a freeze. SRs could still super-review patches,
but they would have the chance to say "sr=bob, but don't checkin until the
next alpha". Part of the reason current freezes are delayed so long, IMO,
is because at the very last minute before the beta freezes, everyone checks
in their coding masterpiece. Naturally it's going to take time for all
these masterpieces to become stable.
d) one week beta freeze. Should be sufficient to make it stable enough.
e) after the one week beta freeze, BRANCH. Don't make us suffer any
longer. After branching and fixing the remaining blockers, make the beta
release.
This plan should also make the beta look more like a beta, instead of a
second alpha. A beta (IMO) should be something that's as close to the
final product as possible. Sure, that's happening now, at the expense of
stretching out the freeze times until everything is happy. In other words,
"Alpha = new stuff in", "Beta = new stuff totally cleaned up", "Final =
oops, we missed something in our total cleanup, but it's fixed now!"
Anyway, my little branching theory is just that, a theory. I don't expect
anything to come of it.
>- Seth emailing module owners and compiling their responses.
Oh, excellent. Please include a questions a long the lines of:
"Are you still a module owner for this module?"
"Are you still interested in this Module?"
"Do you still actively look at the bugs for this module?"
"Are you too busy with your work or another module to spend time with this
module?"
"Do you have any removals or suggested additions to the Peers list for this
module?"
I think some talk about the way GUI changes are handled should be done too
(I'm not sure if that is part of the staff's 'job'). From what I hear, GUI
changes are next to impossible to get implemented, and a "let's add this
GUI element" is more likely to get in than a "let's make this area of the
GUI better".
Okay, I'm done ranting now :)
-Arron
Axel Hecht
I kinda doubt that a mid-term trunk bug-fixing area is a good thing to
do. Note that the long freeze periods led to some pretty strange flowers
the previous times, and we have a decreasing number of developers who
actually can say "well, at least it pays my rent".
If we want a stabilizing period on the current code, let's create a
stable branch.
This will help those modules that are not in a mature state, too. And
yes, there are a few that are not stable.
Having a longer period of tightened tree rules just seems too hard to
communicate to the hearts and souls.
Axel
Boris Zbarsky
> What people's plans are for their modules.
OK. Do you want this in this newsgroup, in some other newsgroup, in
e-mail, in weblogs, in the form of a web page on mozilla.org, in a bug
in bugzilla or elsewhere/in some other form?
Do you prefer a coordinated one-per-module update or are you just
looking to have all module owners and peers outline what they see as the
direction things are going in?
> the Mozilla
> application (in terms of UI and feature count) is fairly complete, and
> there should be a bug-fixing period.
Note that a lot of the nominal module owners for the UI feel that the UI
is in need of a drastic Phoenix-like overhaul instead... But I suppose
that's why you're looking for feedback. You should really mail module
owners involved personally (maybe one mail per module to the owner and
all peers).
A question on Seth's document. That's pretty much limiting itself to
user-visible stuff for now. Are we planning to produce such documents
to cover other parts of the app, such as Gecko? (just trying to budget
time here ;) ).
Gervase Markham
> OK. Do you want this in this newsgroup, in some other newsgroup, in
> e-mail, in weblogs, in the form of a web page on mozilla.org, in a bug
> in bugzilla or elsewhere/in some other form?
Email to st...@mozilla.org in the first instance, please.
> Do you prefer a coordinated one-per-module update or are you just
> looking to have all module owners and peers outline what they see as the
> direction things are going in?
Coordinated one-per-module would be better, but that shouldn't squash
dissenting opinion :-)
> A question on Seth's document. That's pretty much limiting itself to
> user-visible stuff for now. Are we planning to produce such documents
> to cover other parts of the app, such as Gecko? (just trying to budget
> time here ;) ).
Such a document would be produced from the feedback elicited from the
above request :-)
Gerv
Gervase Markham
> communicate to the hearts and souls.
I don't think that tightened tree rules would necessarily be involved;
the process would be driven by the relevant module owners. But as I
said, it's just one point of view.
Gerv
Gervase Markham
>>Minutes of Staff Meeting 2003-01-29
>>-----------------------------------
>>*Direction of the Project*
>>- Drivers say: time to clean up recently-landed features
>>- Discussed progress of GRE and Phoenix projects
>
> Just recently landed features?
For some value of "recently". "Since 1.0" would be a valid value.
> More comminucation is always better. :)
> It would be nice to have the module owners page up-to-date. Everyone knows
> of Black Wednesday, and almost everyone knows who got fired or re-assigned,
> yet those people still sit on the module owners page. I know you change
> the list when people provide new information, however, perhaps a more
> proactive role would be better.
Just because people don't work for NS any more doesn't _necessarily_
mean that they aren't the module owners.
> And since I'm on the topic of module owners, there has also been a lot of
> talk about many module owners not really caring about their modules any
> more, or being too busy with other things. I've personally given up on MO.
> Sure, I'll CC them on a bug if it changes something in their module, but if
> they don't comment, I just pretend they are okay with it.
Appointing module owners is not a trivial process. You can't just say
"Oh, X doesn't want to do it any more, and Y is the only other person
working on the code, so they are the module owner." Having a module
unowned is a valid option, and the idea is that people are module owners
if and when they've demonstrated the skills necessary.
> e) after the one week beta freeze, BRANCH. Don't make us suffer any
> longer. After branching and fixing the remaining blockers, make the beta
> release.
What motivates people to fix blockers on a branch, rather than working
on the trunk? :-)
Gerv
Peter Lairo
>
> *Are we a Distribution?*
There are plenty of "distributions" (Beonex, Netscape) and relatively
stable Milestones (1.0.2, 1.2.1) available already that makes turning
Mozilla entirely into a distribution unnecessary.
Having the pressure off from supplying all the elements of a
distribution (stability, new features, etc.) gives mozilla a lot of
freedom to develop into new directions and make interesting and
promising experiments. Becoming a distribution would hamper a lot of
potential innovation. IMO.
> There was also a discussion of whether each and every milestone needs to
> be a better user experience than the previous one, and if so, how to
> accomplish significant changes.
Please don't worry about end users too much. Make advances were *you*
think they are best. You can always add a feature or two so Netscape can
have something to put on its "What's New" list for it newest version.
Mozilla should maintain it freedom to develop in new and exciting ways. :)
> We also talked about whether the the
> needs of Mozilla end users varies from that of Mozilla developers in
> this regard.
This seems like a superfluous question. :-\
Developers think about the product every day. User don't want to have to
think about the product, if they can avoid it. Therefore, every UI
element and function has to be "inherently obvious to the most casual
observer".
PS. Publishing the meeting minutes is an excellent way of letting the
community know what's going on. Thanks!
--
Peter Lairo
--==--
The Net interprets censorship as damage and routes around it.
--==--
Boris Zbarsky
> What motivates people to fix blockers on a branch, rather than working
> on the trunk? :-)
A sense of professionalism and commitment to the project, one would
think.....
Boris Zbarsky
> Having the pressure off from supplying all the elements of a
> distribution (stability, new features, etc.)
We already worry about stability and new features. Witness the freezes
we have and the contents of the release notes for releases.
> Developers think about the product every day. User don't want to have to
> think about the product, if they can avoid it. Therefore, every UI
> element and function has to be "inherently obvious to the most casual
> observer".
This is only true if the UI is being targeted at users. If it's being
targeted at developers/testers, this is false. Hence the question.
Case in point -- the Debug and QA menus. Should they be present? If we
target at users, no. If we target at testers, absolutely.
The same applies to other UI elements.
Arron
wrote:
>> Just recently landed features?
>For some value of "recently". "Since 1.0" would be a valid value.
Ah, ok. Thanks for clearing that up :) I thought recently might mean
"since 1.2final". Although there's a lot of pre-1.0 features that still
need cleaning up, IMO.
>Appointing module owners is not a trivial process. You can't just say
>"Oh, X doesn't want to do it any more, and Y is the only other person
>working on the code, so they are the module owner." Having a module
>unowned is a valid option, and the idea is that people are module owners
>if and when they've demonstrated the skills necessary.
I'm wasn't talking abou appointing new ones, just find out if the existing
ones care about their module anymore. And if they don't, remove them. I'd
rather have a module with no owner than a module with an owner that doesn't
care or is not doing his/her job.
By removing the MO's name from the list, people start to see there's a need
for developers for that section. It might bring in some new people to the
module. It certainly wouldn't drive people away (I hope?)
>> e) after the one week beta freeze, BRANCH. Don't make us suffer any
>> longer. After branching and fixing the remaining blockers, make the beta
>> release.
>What motivates people to fix blockers on a branch, rather than working
>on the trunk? :-)
Yes, that's why I don't like the phase currently after the alpha release
being open to any patches.. it just causes too many blockers when the beta
freeze happens.
With the two week beta in (c) which only allows bug fixes, one would hope
the blockers would be zero, or at least only one or two. If you can't get
people to fix those one or two blockers, then don't allow any checkins for
the modules they belong under. (ie, if the 2 blockers were in layout, srer
should say "sorry, I'm can't SR any patch in layout other than those
blockers", and force backouts of any checkins that do patch layout until
the blockers are fixed)
-Arron
Mitchell Baker
>
>
> > - We'd like to get input on the roadmap for the different parts of
> > Mozilla from those actually working on the code
>
> What sorts of input are you looking for exactly?
>
>
We'd like to know what developers think:
* ought to happen to the area in which they are working,
* looks possible in the next couple of months,
* would benefit from staff attention (for example, the question of
each milestone being better than the last and the cost this imposes)
* about long term plans, if any
Mozilla.org staff needs to do some planning, and we do not want to plan
in a vacuum. Elaborate plans about the future aren't worth much if they
aren't based in reality. And we can't get close to reality without
knowing what the actual developers have in mind.
Does this help?
Mitchell
Boris Zbarsky
> Surely a UI - a User Interface - by definition is being targeted at Users.
>
> Is this not the case?
Two different meanings of "user". "User of Mozilla" and "typical user
of web browser". The UI is certainly targeted at the former. The
question is how much the former does or should resemble the latter.
Peter Lairo
> Peter Lairo wrote:
>
>> *Are we a Distribution* ?
>
>> Developers think about the product every day. User don't want to have
>> to think about the product, if they can avoid it. Therefore, every UI
>> element and function has to be "inherently obvious to the most casual
>> observer".
>
> This is only true if the UI is being targeted at users. If it's being
> targeted at developers/testers, this is false. Hence the question.
OK, the _target objective_ should be a browser for end-users. To get
there, mozilla.org can add UI elements (and whatever else) that make the
development process easier; but these elements must be *easily
removable* for distributors to be able to easily turn the development
platform into the actual goal: an *end-user browser*. Does that make sense?
> Case in point -- the Debug and QA menus. Should they be present? If we
> target at users, no. If we target at testers, absolutely.
They should remain. (i miss them, particularly the cool tech demos. ;) )
--
Peter Lairo
--==--
"Very funny, Scotty. Now beam down my clothes."
--==--
Gervase Markham
Ah, the naivety of the young :-)
Seriously, this is something we've had a problem with before. Take 1.2,
for example. We shipped that with a serious bug (requiring the 1.2.1
release to put right) because after we branched, QA and development
resource applied to the branch fell right off, because testers wanted
the snazzy new features on the trunk. So, we were on a branch for ages,
and we still didn't ship a good release first time round.
Gerv
Boris Zbarsky
> Ah, the naivety of the young :-)
Heh. See, my statement is correct -- most developers would fix such
blockers (certainly most developers still working on the project).
> because after we branched, QA and development resource applied to the branch
> fell right off, because testers wanted the snazzy new features on the
> trunk.
This is a much more serious problem; keeping testers on the branch would
indeed be very hard....