Closed Bug 125136 Opened 23 years ago Closed 13 years ago

eapp meta bug

Categories

(Core Graveyard :: Tracking, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: hjtoi-bugzilla, Assigned: chofmann)

References

(Depends on 1 open bug)

Details

(Keywords: meta)

Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. I added nsbeta1+
keyword to all of them and made sure the bugs get re-evaluated if they were
targeted beyond 1.0.

I will add proper keywords to this and make the individual eapp bugs block this one.
Most of the blocker bugs are now untargeted - I reset the milestone in a few
that were targeted beyond 1.0.

Statistics: 

* 23 bugs as of now
* 16 untargeted
* 5 mozilla0.9.9
* 2 mozilla1.0
* most doomed engineer is joki@netscape.com with 6 bugs, the rest are nicely
spread out
* 7 major or higher severity* 5 are already DIGbugs
Keywords: meta, nsbeta1+
Target Milestone: --- → mozilla1.0
taking. 

Several of these bugs were nsbeta1+'d without having first been nominated. I
will clean this up this evening. Let me clarify the idea behind the eapp process.

Background
========
Marking bugs with the eapp status was intended to flag bugs that would block
enterprise/intranet web application developers from supporting Netscape 6.
Unfortunately, I have gotten relatively few specific bugs reported by vendors so
far although we are working hard to determine contacts and to collect the actual
list of bugs that would block support for Netscape 6.

The eapp status wasn't meant to short circuit the nomination (nsbeta1), approval
(nsbeta1+), or denial (nsbeta1-) process. I originally intended to use the eapp
marking in triaging bugs which I would, in later stages, nominate nsbeta1 for
approval. The eapp status would then possibly come into play when deciding if
the bug was to be approved or disapproved.

I had envisioned the eapp triaging process to occur in stages:

Stages
========
I. The first stage would be to mark existing bugs which had specific comments
from sun.com, ibm.com, and DIG, etc where they directly mentioned "needed for
customer" or "it would be stupid not to fix this". I have completed this stage.

II. The second stage would be to review the bugs marked with eapp in stage 1 and
nominate for nsbeta1. I have completed this stage. This will quickly get the
issues already identified by enterprise developers on the nomination track.

III. In the third stage the intent is to review outstanding bugs in general, as
well as specific lists of 'must fix' bugs submitted by mozilla.org community
members, and evaluate them according to my own perception of their impact of
enterprise web developers.

This stage would occur while waiting for feedback from the enterprise web
developers.  These bugs would be 'nominated' for eapp status. Since these bugs
would not have a direct request from an enterprise web application developer,
they would not be nominated nsbeta1 automatically. Instead the goal of this
stage is to identify, triage and consolidate existing bug reports so that they
can be more easily understood in terms of their impact on enterprise web
application developers. If I found a bug which I thought deserved to be
nominated nsbeta1 even without a direct enterprise developer request, I would do
so at this stage. Several existing eapp bugs were marked during this stage.

IV. The fourth stage will be taking the direct feedback from the enterprise web
application developers, marking existing bugs, filing any new bugs, and looking
for common patterns of bugs which would indicate specific areas that need
particular attention. This stage would involve the final nominations of eapp
bugs for for nsbeta1.

We are in Stage III now. This will end the week ending 2/15.

Stage IV will probably drag out and due to the delay in hearing from customers
issues will be considered individually.
Assignee: heikki → bclary
eapp was incorrectly used to change this to nsbeta1+. Removing nsbeta1+.

These are important issues and when nominated (nsbeta1) should be considered for
(nsbeta1+) by the ADT.

A bug marked with eapp does not imply that the nomination and approval process
by the ADT is to be short-circuited.


Status: NEW → ASSIGNED
Keywords: nsbeta1+
ADT requested to approve nsbeta1+ for:

Sun/Siebel Issues
bug 124285
bug 123920

Oracle Small Business
bug 92333
bug 112713


Depends on: deflate
Depends on: 81739
Depends on: 56758
Depends on: 128379
No longer depends on: 56758
No longer depends on: 98466
Bug 23679 (NTLM auth) has been implemented on Windows in Mozilla 1.4beta.

There are 15 bugs left (16 on non-Windows platforms) out of 25.
->default
Assignee: bc → general
Status: ASSIGNED → NEW
QA Contact: doronr → general
Product: Browser → Seamonkey
Only 2 bugs of the original 25 are left. Does this meta bug still needs to exist?
The target milestone is overdue anyway :p
Assignee: general → chofmann
Component: General → Tracking
Product: Mozilla Application Suite → Core
QA Contact: general → chofmann
Target Milestone: mozilla1.0 → ---
old netscape tracking bug and this seems to be obsolete
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.