Removing some modules...
Stuart Parmenter
sure that it is current and up-to-date. I've contacted many module
owners about their list of peers and had them update the list or I've
updated it for them so I'm happy to say we now have a fair number of
up-to-date modules listed.
I'd like to start with proposing that we simply delete the following
modules:
* ef (Electrical Fire) -- This hasn't been worked on since 98 afaik.
* Grendel -- maybe 99!
* Image Handling: MNG -- ...
* Java APIs for DOM
* Java APIs to WebShell
* Java Utility Classes
* Java-Implemented Plugins
* none of these have been worked on since 2001 afaict
* Mstone -- no longer being worked on or developed
* NSS Trunk -- this module was replaced by the "security" module and
has no owners/peers/info
* PerlConnect -- dead
* Security Stubs -- dates back to before we had open sourced the crypto
code
* Standalone Composer -- there is no standalone composer that is a
mozilla project
* ViXEn -- old vaporware project
* xmlterm -- the coolest terminal ever but hasn't been worked on in at
least 5 years
I believe that xmlterm is the only one of these with code in the main
tree. Everything else is outside of the directories we pull. I don't
expect this list to be too controversial but please jump in if you
think otherwise.
Here is a list of modules that I also believe we should get rid of but
for various other reasons:
* BeOS-based gfx and widget -- they can no longer compile because of
their old compiler, they aren't ported to thebes so they'll soon break
there.
* Composer -- This should be deleted or renamed to editor core. I
believe the composer stuff used by seamonkey should just be part of the
seamonkey module.
* Find As You Type -- this doesn't need its own module. Part of it is
accessibility, part of it is gecko part is frontend.
* HTML to Text/Postscript -- this is replaced by cairo on the trunk.
For branch issues in this code I think everyone knows who to go to
about it.
* Image Handling JPEG and PNG -- we don't have a GIF or BMP or a hand
ful of others. While these somewhat cover the 3rd party libraries that
we have in our tree I think these should be merged in to the Imagelib
module.
* "Mail/News" -- this should just be merged in with the thunderbird
module (currently "Standalone Composer")
* "News" -- should also be merged in under thunderbird
* NSS Stable Release Branch -- we may want to keep this in despot (for
access control reasons) but just hide it from the owners page as it is
the same as the security module.
* Photon -- this hasn't been worked on in a long time but I'm not sure
the current state of it
* Qt-based gfx and widget -- also hasn't been worked on in a long time
doesn't completely work to my knowledge and isn't supported
* Xlib-based gfx + widget -- same thing. unsupported, not maintained,
etc.
* XPApps -- this is basically SeaMonkey and should just be merged in
with that
* XPrint -- never supported also replaced by cairo on the trunk
* Zlib -- not sure we really need module owners for 3rd party libraries
in the tree. I don't feel very strongly either way about this one
though if people disagree.
I have some more proposed changes but lets see if we can get through
this list first.
Benjamin Smedberg
> * Java APIs for DOM
There have been checkins to mozilla/java/dom as recently as Jan. 1. Please
talk with edburns before proceeding.
> * Standalone Composer -- there is no standalone composer that is a
> mozilla project
This is untrue: mozilla composer should continue to exist as a module,
because glazou is actively working on it and has some stub code committed.
> * BeOS-based gfx and widget -- they can no longer compile because of
> their old compiler, they aren't ported to thebes so they'll soon break
> there.
I think we should keep this around until it's completely unmaintained. The
BeOS guys have been fairly good about keeping up with changes, and I
wouldn't write them off prematurely to get a cairo port.
> * Composer -- This should be deleted or renamed to editor core. I
> believe the composer stuff used by seamonkey should just be part of the
> seamonkey module.
Editor core is necessary. We should think about what to do with the editor
UI, which is still shared SeaMonkey/Thunderbird.
> * HTML to Text/Postscript -- this is replaced by cairo on the trunk.
> For branch issues in this code I think everyone knows who to go to
> about it.
Who's that? /dev/null ? I tend to think we should keep module listings for
code which is still on active branches, even if it has been removed on trunk.
--BDS
Stuart Parmenter
> Stuart Parmenter wrote:
>
> > * BeOS-based gfx and widget -- they can no longer compile because of
> > their old compiler, they aren't ported to thebes so they'll soon break
> > there.
>
> I think we should keep this around until it's completely unmaintained. The
> BeOS guys have been fairly good about keeping up with changes, and I
> wouldn't write them off prematurely to get a cairo port.
>
They actually do have some cairo stuff in the tree (I just
looked/remembered) so they may be OK. I can pull them off on to my
list of stuff we need to see about the owners, etc. I think biesi has
been doing some work there.
> > * Composer -- This should be deleted or renamed to editor core. I
> > believe the composer stuff used by seamonkey should just be part of the
> > seamonkey module.
>
> Editor core is necessary. We should think about what to do with the editor
> UI, which is still shared SeaMonkey/Thunderbird.
>
We might want to add an editor core module regardless. Maybe we need a
SeaMonkey - Composer module? I would think the thunderbird mail editor
stuff would fall under thunderbird.
> > * HTML to Text/Postscript -- this is replaced by cairo on the trunk.
> > For branch issues in this code I think everyone knows who to go to
> > about it.
>
> Who's that? /dev/null ? I tend to think we should keep module listings for
> code which is still on active branches, even if it has been removed on trunk.
>
all the code is under gfx so i'd talk to the gfx module owners. This
just removes a sub-module gfx imho.
Stuart Parmenter
> Stuart Parmenter wrote:
>
> > * Java APIs for DOM
>
> There have been checkins to mozilla/java/dom as recently as Jan. 1. Please
> talk with edburns before proceeding.
>
I'll poke edburns and see what is going on in those areas.
> > * Standalone Composer -- there is no standalone composer that is a
> > mozilla project
>
> This is untrue: mozilla composer should continue to exist as a module,
> because glazou is actively working on it and has some stub code committed.
>
hum. ok.
Wan-Teh Chang
>
> I'd like to start with proposing that we simply delete the following
> modules:
>
> * NSS Trunk -- this module was replaced by the "security" module and
> has no owners/peers/info
> * Security Stubs -- dates back to before we had open sourced the crypto
> code
I agree. I filed a request to have these two modules deleted:
https://bugzilla.mozilla.org/show_bug.cgi?id=316141
> Here is a list of modules that I also believe we should get rid of but
> for various other reasons:
>
[...]
> * NSS Stable Release Branch -- we may want to keep this in despot (for
> access control reasons) but just hide it from the owners page as it is
> the same as the security module.
I agree. This module is only needed in despot for CVS commit
access control.
Please give the "Client NSPR" module the same treatment. It
is only needed in despot for CVS commit access control.
We should also reopen my request to have the "Berkeley DB" module
removed because mozilla/dbm is now only used by NSS. The request is
https://bugzilla.mozilla.org/show_bug.cgi?id=318173
Wan-Teh
Stuart Parmenter
Great. I'll take care of those bugs when I take care of the rest of
these modules. dbm was on my next list of things to bring up but I
wasn't sure what the status of it was. I'll add it to my list of
things to remove and put mozilla/dbm under the NSS module?
stuart
Wan-Teh Chang
>
> dbm was on my next list of things to bring up but I
> wasn't sure what the status of it was. I'll add it to my list of
> things to remove and put mozilla/dbm under the NSS module?
Yes, please put mozilla/dbm under the "Security" (NSS) module.
Wan-Teh
bre...@mozilla.org
standalone composer, and other replies. It sounds like the situation
for the trunk will get a lot simpler. Mozilla 2 will have a new
repository and even fewer modules (although any file could be its own
module; what I mean is what I think you are getting at: fewer top-level
modules).
/be
Simon Paquet
> I'd like to start with proposing that we simply delete the following
> modules:
>
> * Grendel -- maybe 99!
I've seen real changes to this in Decemeber 2005 and code misspelling
corrections in 2006. So I would suggest that you talk to the
maintainers R.J. Keller (rj.k...@beonex.com), and Jeff Galyan
(jeffrey...@sun.com) before proceeding with this.
> * BeOS-based gfx and widget -- they can no longer compile because of
> their old compiler, they aren't ported to thebes so they'll soon break
> there.
Others have already posted about this.
> * Photon -- this hasn't been worked on in a long time but I'm not sure
> the current state of it
Apart from some cleanup checkins, which also affected Photon, this has
seen its last real photon-only checkin in January 2006. Therefore you
should probably talk to the maintainer amar...@qnx.com before
proceeding with this.
> * Qt-based gfx and widget -- also hasn't been worked on in a long time
> doesn't completely work to my knowledge and isn't supported
> * Xlib-based gfx + widget -- same thing. unsupported, not maintained,
> etc.
In general it might not hurt to also post this info to the ports
newsgroup/mailinglist, because some of this might also affect the ports
owners, if those still exist (I don't know).
Stuart Parmenter
>
> * "Mail/News" -- this should just be merged in with the thunderbird
> module (currently "Standalone Composer")
> * "News" -- should also be merged in under thunderbird
I talked to Scott MacGregor today and we agreed to remove News. We'll
keep "Mail/News" and probably rename it to "Mail Backend" since it is
shared between thunderbird and seamonkey
Stuart Parmenter
Wan-Teh Chang wrote:
> Stuart Parmenter wrote:
> >
> > I'd like to start with proposing that we simply delete the following
> > modules:
> >
> [...]
> > * NSS Trunk -- this module was replaced by the "security" module and
> > has no owners/peers/info
> [...]
> > * Security Stubs -- dates back to before we had open sourced the crypto
> > code
>
> I agree. I filed a request to have these two modules deleted:
> https://bugzilla.mozilla.org/show_bug.cgi?id=316141
>
> > Here is a list of modules that I also believe we should get rid of but
> > for various other reasons:
> >
> [...]
> > * NSS Stable Release Branch -- we may want to keep this in despot (for
> > access control reasons) but just hide it from the owners page as it is
> > the same as the security module.
>
> I agree. This module is only needed in despot for CVS commit
> access control.
>
> Please give the "Client NSPR" module the same treatment. It
> is only needed in despot for CVS commit access control.
>
OK. I have gone ahead and removed the 2 dead modules and I have hidden
Client NSPR and NSS Stable Release Branch from the owners.html page
(they are still listed in despot)
> We should also reopen my request to have the "Berkeley DB" module
> removed because mozilla/dbm is now only used by NSS. The request is
> https://bugzilla.mozilla.org/show_bug.cgi?id=318173
I'll follow up on this in the bug.
Mike Connor
roll in into whatever we end up with for suite.
extensions/typeaheadfind is only used by suite, there's a new FAYT
impl in toolkit. Currently part of the unowned Find As You Type module
extensions/help is only used by suite, there's a separate help impl
in toolkit. Currently part of the Help System module
extensions/p3p is not built for Firefox, and is unlikely to be at any
point going forward. Currently unofficially handled under the
cookies module
extensions/wallet is not built for Firefox, and is unlikely to be at
any point going forward. Currently unofficially handled under the
cookies module
extensions/permissions is part of Cookies and Permissions, but not
reflected in despot (netwerk/cookie should be part of that module for
now)
There's a ton more that don't have despot info but should get owners
or should be dropped from CVS
Stuart mentioned Vixen
extensions/transformix doesn't exist, so it should be pruned from XSLT
tridentprofile doesn't seem to be built, and hasn't been touched
since 2003
extensions/irc is Chatzilla and should have a module
extensions/xforms is obvious and should have a module
there's a number of others, this was a fast pass.
-- Mike
Axel Hecht
> There's a bunch of stuff that's suite-only at this point and should roll
> in into whatever we end up with for suite.
>
> extensions/typeaheadfind is only used by suite, there's a new FAYT impl
> in toolkit. Currently part of the unowned Find As You Type module
> extensions/help is only used by suite, there's a separate help impl in
> toolkit. Currently part of the Help System module
> extensions/p3p is not built for Firefox, and is unlikely to be at any
> point going forward. Currently unofficially handled under the cookies
> module
> extensions/wallet is not built for Firefox, and is unlikely to be at any
> point going forward. Currently unofficially handled under the cookies
> module
>
> extensions/permissions is part of Cookies and Permissions, but not
> reflected in despot (netwerk/cookie should be part of that module for now)
>
> There's a ton more that don't have despot info but should get owners or
> should be dropped from CVS
>
> Stuart mentioned Vixen
>
> extensions/transformix doesn't exist, so it should be pruned from XSLT
extensions/transformiix was moved to content/xslt lately, but still
exists on the MOZILLA_1_8(_0)?_BRANCHes.
Axel
Michiel van Leeuwen
> extensions/wallet is not built for Firefox, and is unlikely to be at any
> point going forward. Currently unofficially handled under the cookies
> module
But wallet is still build for thunderbird. It does the password
management there. (but really, thunderbird should switch to the toolkit
version of pwdmgt)
Michiel
Boris Zbarsky
> I believe that xmlterm is the only one of these with code in the main
> tree.
I believe we should rectify this and CVS remove it. ;)
> * Composer -- This should be deleted or renamed to editor core. I
> believe the composer stuff used by seamonkey should just be part of the
> seamonkey module.
We need at least an Editor Core module and Composer UI module. Going forward we
might want to split apart "Editor Core" and "HTML Editor" as well, if we ever
get serious about editing...
> * Find As You Type -- this doesn't need its own module. Part of it is
> accessibility, part of it is gecko part is frontend.
We can lump the two FAYT impls under toolkit and seamonkey, imo. But it's kinda
unowned, no matter what....
> * "Mail/News" -- this should just be merged in with the thunderbird
> module (currently "Standalone Composer")
There's Mail/News back end, which should imo be a separate module from
Thunderbird (front end) and Seamonkey (different front end).
-Boris
edburns
following
SP> modules:
SP> * Java APIs for DOM
SP> * Java APIs to WebShell
SP> * Java Utility Classes
SP> * Java-Implemented Plugins
SP> * none of these have been worked on since 2001 afaict
Not true for these. I've been making checkins in this code for a long
time. Just made one today, in fact.
SP> I believe that xmlterm is the only one of these with code in the
main
SP> tree. Everything else is outside of the directories we pull. I
don't
SP> expect this list to be too controversial but please jump in if you
SP> think otherwise.
Please do not delete the Java* stuff in the mozilla/java directory.
However, you can remove the mozilla/java/xpcom directory and its
contents. This has been totally superceded by the work done by Javier
Pedemonte.
Ed
Stuart Parmenter
> Stuart Parmenter wrote:
>
> > I'd like to start with proposing that we simply delete the following
> > modules:
> >
> > * Grendel -- maybe 99!
>
> I've seen real changes to this in Decemeber 2005 and code misspelling
> corrections in 2006. So I would suggest that you talk to the
> maintainers R.J. Keller (rj.k...@beonex.com), and Jeff Galyan
> (jeffrey...@sun.com) before proceeding with this.
>
R.J. Keller's email address bounces. I'll try Jeffrey. If both end up
bouncing I'll probably go ahead and remove it unless someone else
objects.
Mike Shaver
It's not like we're going to remove the repository ,v files and burn
the backups -- they can certainly put it in another repository
somewhere if they want to revive it somehow. (If I were them, I'd
jump at the chance!)
Mike
Nunya Bidness
> R.J. Keller's email address bounces. I'll try Jeffrey. If both end up
> bouncing I'll probably go ahead and remove it unless someone else
> objects.
>
Here's another one from one of his mozdev projects:
r...@trfenv.com
Stuart Parmenter
remove Grendel.
On Jan 22, 6:21 pm, Nunya Bidness <us...@invalid.domain> wrote:
> Stuart Parmenter wrote:
> > R.J. Keller's email address bounces. I'll try Jeffrey. If both end up
> > bouncing I'll probably go ahead and remove it unless someone else
> > objects.Here's another one from one of his mozdev projects:
> r...@trfenv.com