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

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.

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.

ADT requested to approve nsbeta1+ for: Sun/Siebel Issues bug 124285 bug 123920 Oracle Small Business bug 92333 bug 112713

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

Only 2 bugs of the original 25 are left. Does this meta bug still needs to exist? The target milestone is overdue anyway :p

old netscape tracking bug and this seems to be obsolete