453975 - [meta] Tracking bug to purge Mork from all Mozilla codebase

Status: NEW

(MailNews Core :: Database, task, P3)

Description

[David Aznar Reguero]

User-Agent:       Mozilla/5.0 (X11; rv:1.8.1.11) Gecko/20071128
Build Identifier: 

Now that most Mozilla code is migrating to mozStorage is is time to purge the painful Mork from Mozilla codebase.
This a meta bug, so it should depend on any request to port from Mork to mozStorage.
It should probably block all Mork bugs since maybe work should be done in porting from Mork to mozStorage instead of trying to fix Mork bugs.

Reproducible: Always

Comment 1

[Matthias Versen [:Matti]]

isn't mork still used in Seamonkey and Thunderbird ?

Comment 2

[David Aznar Reguero]

(In reply to comment #1)
> isn't mork still used in Seamonkey and Thunderbird ?

That is what this bug is for. To keep track of the modules that are still using Mork. Please make this bug depend on any bug to port any module from Mork, or if you know any module that still use Mork and there is no bug filled please file a bug and make this bug depend on it.

Comment 3

[Worcester12345]

Can bug 1669589 block this?

Comment 4

[chrizilla]

Shouldn't this meta bug and all of its dependent bugs be assigned a higher priority and/or severity since Mork is prone to data corruption and data loss ?

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to chrizilla from comment #4)

Shouldn't this meta bug and all of its dependent bugs be assigned a higher priority and/or severity since Mork is prone to data corruption and data loss ?

The remaining work is much more complex than bug 382876 and bug 418551. Changing these fields in bugzilla will not change the speed of that work, unfortunately. But over the past few years there has been steady progress behind the scenes to complete the remaining dependencies.

Comment 6

[chrizilla]

(In reply to Wayne Mery (:wsmwk) from comment #5)

I'm fully aware of the complexities involved and didn't expect a speed-up from changing priority/severity. But these fields probably do serve some purpose, so I thought maybe they should be adequately set. In some (of the currently 4) open dependent bugs, for example in bug 1726662, both fields are unset. In others priority/severity is very low.
I was worried that people who survey open critical issues (e.g. through advanced search) might miss these issues due to unset fields.
https://firefox-source-docs.mozilla.org/bug-mgmt/policies/triage-bugzilla.html says: "We want to make sure that we looked at every defect and a severity has been defined."

Comment 7

[Tommy Hallem]

Attachment: same problem

Thanks from petvedarfi1970.