[Resending, this didn't make it to the newsgroups for some reason,
although there were Newsgroup: headers in my reply window. /be]
H�kan Waara wrote:
> Axel Hecht wrote:
>
>> Hi,
>> it might be worth starting to give out info on the target milestone for
>> 1.0. The roadmap still has some hint on 0.9.4 = 1.0, though I doubt that
>> after searching for a few Hixie-Ps.
>>
>> Anyway, it's triage time as Chris said, and people should know whether
>> they triage 0.9.4 or 1.0.
>
>
> I agree with Axel's comments.
>
> Speaking of which, is it possible (wrt. milestone periods) that we
> could make the 1.0 period a bit longer than usual?
>
> That way, with drivers' help, we could catch up on stability once
> again and make 1.0 the most stable milestone ever.
>
Good ideas all, and they have occurred to us too, recently. Gervase
Markham (now [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>) is helping
greatly with the push for 1.0, and may have more to say, but I already
have been singing this tune to all who will listen, starting at the
O'Reilly Open Source Conference last month in San Diego. I'll do a
command performance of it in a separate posting. Here's another
run-through:
1. We intend to add target milestones through at least 0.9.7, and
milestone keywords for nominations. As we've said often, we're not
looking for new features; we want stability, performance, standards
compliance, and good APIs.
2. Mozilla consumers, including many companies developing products, need
a stable, long-lived branch with API commitments, library versioning (so
at least they can know when to upgrade or bundle a new rev to replace a
downrev .dll or .so), stability, good performance, and
better-than-any-competition standards compliance. This need is acute:
if mozilla.org does not create such a branch to share or to branch from
for individual companies and organizations, various consumers of the
code will do it themselves, with less sharing and coordination than we
would like.
We think the world will be a better place, with more hands helping to
improve Mozilla, and more people benefiting from distributions of
Mozilla, if mozilla.org hosts a consolidated stable/long-lived branch
along with the active, ongoing development of the trunk. This branch
obviously entails overhead in driving, merging, reviewing, and testing.
We're not sure exactly how it will be managed (what its roadmap will
be), yet -- but we see the need, we want to have a plan, and we welcome
your input.
3. This stable, long-lived, _branded_ branch cannot happen without
concerted effort to fix certain bugs. We need to identify the bugs and
drive the buglist to near-zero. To do that, without being utterly
date-driven, we need to pick a small number of milestones during which
we ask developers to schedule fixes for their mozilla1.0 bugs. Of
course, contributors have different ideas about what constitutes a
mozilla1.0 bug. Some people (hi, Hixie!) believe that most
standards-compliance bugs should be fixed for anything that deserves the
1.0 brand. That's ok, but the number of milestones to fix such a long
list is unknowable and large -- years at a guess.
Given the constraints identified in item (2) above, we still have a
short-term requirement for a stable, relatively long-lived (a year, at a
guess) branch. However we brand this release and branch, we need to a
schedule that converges on a stable, useful release in at most six
milestones, preferably fewer (but likely no fewer than four). So we are
starting to ask people to schedule their most important mozilla1.0
bugfixes over the four milestones starting with 0.9.4, through 0.9.7.
Long story short: we need a schedule for the short term that culminates
in a release with stable code and APIs (APIs broadly construed: XUL
syntax is an API, as are XUL semantics; but not every C++ or XPCOM API
will be public or frozen, see http://www.mozilla.org/projects/embedding/).
4. The majority of drivers surveyed in a straw poll (this is not a final
decision!) believes that the "1.0" brand should be used sooner rather
than later to identify this stable, long-lived branch with API commitments.
5. We believe that a milestone where only fixes for topcrashes and other
severe bugs (e.g., dataloss) get checked in, with lots of regression
testing and code review, is necessary before we can confidently brand a
"1.0". This is effectively a double-milestone with a release in the
middle to get more testing and talkback, and it addresses hwaara's
concern above about a longer 1.0 milestone.
All of this taken together suggests that we have at most 0.9.4 through
0.9.9 to get to a mozilla1.0 branch cut. There's obviously a lot of
work to do, and more to be said about how to organize that work, but
I'll leave that for the command performance. Your feedback is welcome.
/be
