Closed Bug 98281 Opened 23 years ago Closed 23 years ago

nsISupports needs freezing

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: jud, Assigned: dougt)

References

Details

Attachments

(7 files)

doesn't compile diff - basic idea of what I proposed.
19.47 KB, patch
Details | Diff | Splinter Review
simplier patch
18.17 KB, patch
Details | Diff | Splinter Review
factors out obsolete stuff.
56.00 KB, patch
Details | Diff | Splinter Review
more factoring
198.67 KB, patch
Details | Diff | Splinter Review
changes outside of xpcom/base for patch 49671
4.02 KB, patch
Details | Diff | Splinter Review
mozilla/ patch with David's suggestion
201.15 KB, patch
Details | Diff | Splinter Review
more changes by rick
201.51 KB, patch
jud
: review+
rpotts
: superreview+
Details | Diff | Splinter Review
what's the #if 0 stuff in nsISupports.idl for? we need to: - ditch the "#include 'nsISupportsUtils.h'" from the idl, and sprinkle it around to the #include nsISupports locations. - comment the iface. - add "@status FROZEN" to the iface comments.
Blocks: 98276
Blocks: 98278
> we need to:... You don't say *why*. One original motivation fo this trickery that that at one time on Mac they needed the nsISupports interface to inherit from the magic __comobject type that made the vtbl layout come out the way they wanted it to - on debug builds only IIRC. They've since done away with that. The remaining problems are... - You would be 'sprinkling' "#include 'nsISupportsUtils.h'" almost everywhere, no? As it is now C++ files get what they need by #including pretty much any xpidl generated interface header. - There is an ordering proplem. nsISupports.h uses NS_NO_VTABLE that is #define'd at the beginning of nsISupportsUtils.h and most of nsISupportsUtils.h requires nsISupports to have been declared. I don't think this is really broken - it is just ugly. So I don't see the need to change it. So why not just add "@status FROZEN" to nsISupports.idl and call it quits?
what an "@status FROZEN" mean when it just includes another file? :-) How about we create a new file for C++ callers which defines the nsISupports? This way do we not have to freeze the nsISupportsUtil.h header.
> what an "@status FROZEN" mean when it just includes another file? :-) You are freezing the interface. nsISupports is not going to change. > How about we create a new file for C++ callers which defines the nsISupports? > This way do we not have to freeze the nsISupportsUtil.h header. I don't know what this means. I still say this is not broken. We have have mechanism in place for the C++ #includers to get what they need without hassle and without impact on the other languages that rely on nsISupport.idl.
re: why... part of the motivation here is to allow compile time backwards compatibility. I should be able to #include nsISupports.h in my c code and not have to worry about it changing (causing dependency rebuilds for example). so, it sounds like we can rip out the #if 0 stuff; cool. yea, the "sprinkling" bugs me, I'm not sure how to get around it :-/. it's ugly, but I wonder if it's a necessary evil.? Freezing an interface freezes it's entrails/dependencies. all of our other frozen/freezing interfaces abide by this rule, making nsISupports an exception breaks the core rule/model, and no-one else should bother following it either (rat's nest).
> so, it sounds like we can rip out the #if 0 stuff; cool. No. Look at the ordering in the use of NS_NO_VTABLE. I think that the cure you suggest is *far* worse than the disease. We are talking about the mechanism by which we pull in the core support code for xpcom as used by C++. It is better to make a documented exception to your "frozen rule" then to inject clumbsyness for the sake of pure rules. You might think about how to partition nsISupportUtils.h (yuk!). But *some* of it is absolutely necessary in order to use xpcom from C++. Let's not fool ourselves.
> No. Look at the ordering in the use of NS_NO_VTABLE. got it. > I think that the cure you suggest is *far* worse than the disease. I think you're right here. I suppose this means we indeed pull nsISupportsUtils.h apart :-/
jband: what I meant was exactly what you suggest. split the private stuff out of nsISupportUtils.h. there are a ton of macros, helper functions and includes that do not need to be exposed (eg. nsTraceRefCnt.h). What is really required by a c++ user? That is the minimun set that we should expose, right? What I suggested was that the nsISupports.idl should #include a header which defines only what is absolutely required. I think that this is the right thing to do. :-)
In order to reduce the #include fan out cause by exposing nsISupports.idl, I think that we can factor out just what is required. I created a new file that nsISupports.idl includes (namely nsISupportsBase.h). In this file, I moved the declaration of nsISupports. I also had to move the typedef of "nsresult" (from nsDebug.h). So, now nsISupports.idl can be frozen with the minimal fan out: nsISupportsBase.h nscore.h nsCom.h (I moved the setters/getters to nsISupportsUtils.h) nsID.h nsIID.h Now, for callers that want to use the macros and utility functions as defined in nsISupportsUtils, they can directly include this file (and its fanout). So the big drawback is that I will have to sprinkle #include "nsISupportUtils.h" in a bunch of places. Thoughts on this approach?
that last patch is kind of my handwaving at what I proposed. If we agree that this is the way to factor, I will continued down this path.
It's not immediately obvious to me that the fan out is significantly reduced. The NS_IMPL macros are used everywhere, no?
It reduces two immediate headers: nsDebug and nsTraceRefcnt. These two are not too bad, but they do not have to be frozen. The real problem is nsISupportsUtils.h itself. I am not positive that we really want to expose all of these marcros to embedding clients of XPCOM. I would much rather have this header file (and its implementation) be part of an optional static library that these clients can link to. Thoughts?
If we don't want others to use nsISupportsUtils.h's macros, then I have to wonder why we use them. The same rationale will apply to anyone seriously implementing nsISupports-derived types. We went to a lot of work to rewrite code that rolled its own QI, AddRef, and Release methods, and IIRC care was taken also to allow the QI macros to be composable, yet still not dictate an if-else control flow implementation (allowing, e.g., a table-driven approach). Why would we want others to reinvent this wheel? If you just want to avoid entraining nsTraceRefcnt.h and nsDebug.h, there are easier solutions. However, we should in no wise foist a new pair of direct #includes on every .cpp file in the tree. Cc'ing dbaron. /be
> If we don't want others to use nsISupportsUtils.h's macros, > then I have to wonder why we use them. we're more tolerant and we pull the tree all the time. external folks aren't as interested in keeping up w/ all our mods to core stuff. I'm all for pushing as much of our stuff out as we can, but we're trying to freeze things here which generally means minimizing exposure a great deal. From this point forward, various things (interfaces, MACROS, classes, etc) will be frozen. We need to be sure we can live w/ the things we freeze, and living w/ as small a set as possible is easier :-). I'm not a fan of pumping #include joy all over the tree either, but, it helps solve the technical problem of "what do we freeze." It's not pretty, but it does force a nice clean separation between what's frozen and what's not. IMO, pushing #includes around is fine (it's certainly not hard work). It's not as pretty as it could be, but that's the world we've built (I think :-/). Alternatives welcome :-).
Rather than multiply direct #includes in existing files, we should provide composite .h files that can be included. Existing clients of nsISupports.h who use the nsISupportsUtils.h macros would include nsISupportsImpl.h (e.g. -- make up a better name if you can). nsISupportsImpl.h would be just two nested, #if-idempotent #includes, of nsISupports.h and nsISupportsUtils.h. BTW, there is just about zero burden, apart from compile time, on clients of nsISupportsUtils.h, so I don't buy the "we're more tolerant" argument. The only changes there have been extensions (THREADSAFE, CI-for-ClassInfo, debugging hooks). Again, if embedders start seriously implementing XPCOM classes, they *will* want nsISupportsUtils.h. Your freeze-effort bandwidth limitations won't stop that want, and shouldn't frustrate it, or everyone will reinvent the wheel, rediscover the same bugs and botches, etc. /be
Currently we get all the nsISupportsUtil.h stuff by simply including nsISupports.h (or any generated header file that included nsISupports.idl). I *still* don't see any reason to break that - and you *will* be breaking others' code when you change what's in the tree. Perhaps mozilla embedders who want some minimum xpcom header set should have to #define some symbol that would control what is automatically #included by the #include of nsISupports.h?
> BTW, there is just about zero burden, apart from compile time, on clients of > nsISupportsUtils.h, so I don't buy the "we're more tolerant" argument. believe it or not we get bitched out (via mozilla contacts) for mod'ing the core because it blows depend build compile times. > The only > changes there have been extensions (THREADSAFE, CI-for-ClassInfo, debugging > hooks). then perhaps it's closer to freezing than we're guesstimating ;-) > Again, if embedders start seriously implementing XPCOM classes, they > *will* want nsISupportsUtils.h. Your freeze-effort bandwidth limitations won't > stop that want, and shouldn't frustrate it, or everyone will reinvent the wheel, > rediscover the same bugs and botches, etc. for sure, that's fine. then are you pushing for a full freeze of the full utils? we've been trying to contain the freeze dammage here... making small lists. do you have a better approach?
> I > *still* don't see any reason to break that - and you *will* be breaking others' > code when you change what's in the tree. nothing new there, we break customers everyday. the whole idea behind freezing is to minimize this (we've never bothered trying) in the future, there's a step #1, and that's what we're trying to get to here. there's a difference between raw/general mozilla tree usage (use at your own risk), and usage of ifaces/etc that are expected to be frozen. again, we're trying to make a break here and get some pieces moving in the frozen direction. > Perhaps mozilla embedders who want some minimum xpcom header set should have to > #define some symbol that would control what is automatically #included by the > #include of nsISupports.h? hmmm, interesting. maybe a #define STRICT_INCLUDE or something. it adds an extra layer I wish we could avoid (also allows us to cop out :-/), but perhaps this would elleviate pain in other areas as well.
Maybe what we need is a macro, defined by the build system, that says whether we're building code that's going to be linked against the XPCOM library? This would allow us to make the macros usable (although without their debugging features) when not linking against XPCOM. (Do the embedders for which we're trying to freeze stuff typically link against XPCOM? Should they?)
there are two groups of people (probably more, but for the sake of arguement). The first group wants to code inside of mozilla. MailNews is a good example of this group. They have accepted the fact, for better or worse, that the API is in flux. I think we all can agree here. The other group, is a bit more shy. They don't have the resources to keep up with the ever changing symbols, apis, semantec, ect. They just want to be plugged in at the right places having those interfaces well defined, well documented, and completely frozen. A good example of this group is say Adobe's plugin. They really don't care about all of the magical things that Mr. Mozilla Potter can do. Now, I am not tackling this first group right now. If you want to live and play directly in mozilla, feel free. But it is very tempting to link to something that is available yet not frozen. Some of the developer that do this do not have the benefit of being "patched" when someone changes the API on them. Babysteps... We will get there. For now, I would like to address the minimun API required by the two groups that want this the most: embedding and plugins. Both of these clients only need a very slim api. They are not concern about most of the stuff that XPCOM can provide. They pretty much need startup, shutdown, component handling. So, going back to the patch, I think factoring out the base requirements of this interface (nsISupports) and excluding, for now, anything that is either in flux or requires a link to XPCOM is a good cut. There are some classes and utils that will require a link to xpcom, but rick and I discussed this at length. What we should do for this case, is create a static library (snapshot) of these utils. We can hand this static build off to groups that need this kind of functionality (nsCOMPtr, strings, util functions). In the mean time, xpcom does not have to freeze these api's.
dougt, jud: I think your approach is good (start small, work up). But I fear jband is right. Here's a solution that's ugly, but that satifies all the dependency constraints: 1. Make a new nsISupportsOnly.h (or whatever we should call it) that includes just the minimal type definitions. Can this be a .idl file? Is the only reason we use the %{C++ #if 0 %} hack in nsISupports.idl, namely so we can insert __comobject as a public base class on the Mac, no longer done? 2. Make nsISupports.h include nsISupportsOnly.h and nsISupportsUtils.h. 3. Purvey nsISupportsOnly.h to embedders who want to minimize dependencies, and to anyone who is not *implementing* an nsISupports-derived type. Comments on this Hegelian dialectic in action welcome! /be
> Is the only reason we use the %{C++ #if 0 %} hack See my first comment in the bug. In our tree at present nsISupports has no parent on any platform. but there is stuff to be #defined before nsISupports is declared - NS_NO_VTABLE. > 1. Make a new nsISupportsOnly.h (or whatever we should call it) that includes > just the minimal type definitions. Recall that we generate... #ifndef __gen_nsISupports_h__ #include "nsISupports.h" #endif ... into every generated .h file whose .idl file has #include "nsISupports.idl" I say that this should not change. nsISupports.h should pull in some header - nsISupportsUtils.h or whatever - and *that* header should decide what else to pull in. I think it would suck to have my C++ have: #include "nsISomeFrozenInterfaceThatIncludesnsISupports.h" #include "nsISomeOtherFrozenInterfaceThatIncludesnsISupports.h" #include "TheMozillsInternalHeaders.h" #include "StuffThatReliesOnTheMozillsInternalHeaders.h" #include "OtherStuffThatReliesOnTheMozillsInternalHeaders.h" I expect we are going to inevitably end up with some macro or another that gets #define'd differently depending on whether or not the "TheMozillsInternalHeaders.h" have been included yet or not. That is why I was suggesting a build flag that would say *upfront* which mode the project is being built in.
actually step three is a even more simplified. Since the nsISupports.idl is effectively useless for c++ users now (it is nothing more than a redirect to nsISupportsUtils). We factor out the core stuff from nsISupportsUtils, and call it nsISupportsOnly.h (or whatever) and this is the only file we give to anyone doing C++ dev. They can still derive from it without any problems. (am I missing something). This kepts us from #including 80+ places (not like I haven't done this already :-/) This same problem is going to come up again and again for many of the xpcom interface. What do we do when there are utility classes/functions in the xpidl that have a large fan out? I spoke to a few people and the idea was to move these helpers into a new nsIFooUtils.h file, and #include where needed. What are your thoughts on that? Brendan, jband?
that number 80+ was for another bug (nsIWeakReference) which needs to have the same thing done (remove C++ code, put it somewhere so clients don't ahve to see it)
It seems like we're getting bogged down here :-) As far as i can see, we need the stuff that's currently defined in nsISupportsUtils.h to be split into two distinct header files : - one for interface consumers. This one would define NS_NO_VTABLE, provide the actual nsISupports definition and contain any helper macros that are needed/useful when 'calling' nsISupports derived interfaces. - one for interface implementors. This one would have all of the macros used to implement nsISupports. Then, nsISupports could still #include nsISupportsUtils.h (which is stripped down for interface consumers). Components that 'implement' ISupports could #include a new header 'nsISupportsImpl.h' which provides the implementation macros... I realize that this will require adding a new header to component implementations, but i think that the benefits far outway the work. Perhaps, nsISupportsImpl.h is a bad name, maybe nsComponentImpl.h or some other 'component' type name would be better... After all we *are* talking about component implementations... There is a somewhat orthoganal issue of how to factor out the DEBUG and RefCount Tracing references in these two headers... Perhaps, we will need to include the refcount tracing APIs as part of the static library (i'm talking about ns_if_addref() and any other friends it needs) And finally, there is a certain amount of cruft that should be *removed*: - NS_LOCK_INSTANCE() / NS_UNLOCK_INSTANCE() and all of the PRCMonitor references... - NS_ITHREADSAFE_IID and NS_VERIFY_THREADSAFE_INTERFACE - I'd also argue that we don't need NS_IMPL_ISUPPORTSx any more either... just using NS_IMPL_ADDREF / RELEASE / INTERFACE_MAP would be much simpler to maintain... but this one is just my opinion :-)
ok... i realize that i took a few too many hits off the old API purity crack pipe and lost track of reality a bit in my last set of comments :-) i realize that it is *not* reasonable to force component implementors to #include a new header file... However, i still think that there is value in splitting the existing nsISupportsUtils.h into two distinct files. one for interface consumers and one for interface implementors. Even if both of these headers get included... -- rick
How is this: (brendan's suggestion) 1 Factor our the minimal nsISupports stuff into a nsISupportsOnly.h 2 Make nsISupports.idl include both this new header and nsISupportUtils.h 3 Freeze nsISupportsOnly.h, and nsISupports.idl 4 In the C++ SDK, only ship nsISupportsOnly.h (including nsISupportsUtils.h in the idl prevents us from having to add #include "nsISupportsOnly.h" everywhere)
so, here is what jud, rick, and I discussed this morning: We split out the required C++ stuff into a seperate header file, nsISupportsBase.h. Then, we #include this file in the IDL. The nsISupportsUtils.h which contains helper routines and other stuff can be included in the IDL as well, but it will be wrapped with a macro similar to that STRICT macro used in windows 3.51/40 4.x. When a client wants to build without linking to a bunch of places in xpcom, they can define this build directive. thoughts?
I just realized that an embedding dev "package" would still be required to deliver the *Utils.h (or whatever) files. maybe we put the #ifdef in the idl, so we don't have to deliver the .h's if folks don't want them?
hey jud, that's what i was imagining... in each IDL file that has extra "support" definitions we would have something like this: %{C++ #ifndef MOZ_STRICT_API #include "nsIxxxUtils.h" #endif %}
sounds right to me
Can we use MOZILLA_STRICT_API instead? Just defending against mozzarella confusion. :-) /me looks forward to a patch that can be tested against jband's fears that we'll break existing users /be
Attached patch simplier patch — — Splinter Review
patch 49059 builds fine on windows. still need to verify it is cool on mac and 'nix. What do y'all think so far? Is this the way we should attack similar interfaces?
hey doug, i think that this looks fine... in this case, however, i'm wondering if we don't want to split some of the cruft out of nsISupportsUtils.h and into some sort of 'obsolete definitions' header - such as nsISupportsObsolete.h i'm really not sure that we want to publically promote wacky macros like NS_IMPL_CLASS_GETTER / SETTER. Macros like this only serve to obscure the code and make it harder to debug. i'm sure that there is other cruft in nsISupportsUtils that we would rather 'forget' too ;-)
Yeah. that is a good idea. I will work on that next. stay tuned.
I'm pretty much OK with this. One question, Why not just put... +#ifndef MOZILLA_STRICT_API +#include "nsISupportsUtils.h" +#endif ...in nsISupportsBase.h rather than in the idl file?
we want it in the .idl, so in a STRICT dist, we wouldn't even have to bother packaging the .h. if it's in the .h, and someone doesn't want to use it, they still have to include the .h.
rick, can you give this patch a once over?
hey doug... this patch makes my head hurt!! I think that it looks fine to me. I'm sure what once we make the distinction between 'utils' and 'obsolete' stuff we can start arguing about what *really* is obsolete :-) btw, jband was suggesting that we may want to call it 'depricated' rather than 'obsolete'... so "nsISupportsDepricated.h"
try applying the diff and looking at the two new files. That is the only way I could make sense of the patch... :-) I like nsISupportsDeprecated more too. Anyone else have an opinion
Yes, deprecate now, obsolete later. If we move fast, we can do it by 1.0. If we find too many entrenched, hard-to-change users, 2.0. I'll look at the patches and explode my head later tonight. /be
Attached patch more factoring — — Splinter Review
After talking with rick some about this, we decided that the best approach was to continue factoring out to the C++ headers. From this we created a few new files: A nsISupportsBase.h This is the nsISupports defination for C++. It is included from the nsISupports.idl. This file is the minimum needed to use nsISupports. A nsiSupportsImpl.h If you are implementing a nsISupports object, this file is pretty helpful. It includes all of our IMPL_ISUPPORTS macros. A nsComDeprecated.h This file is the cruft that should have been moved into the components. All of the #defines in here control how functions are exported/imported. (should this be renamed?) A nsISupportsObsolete.h These are all of the macros, and functions which should not be used anymore.
Hey doug (catching up on my mail still, I owe you comments today -- sorry for the delay), how come you had to move some nsI*.h above nsVoidArray.h includes, e.g., +++ nsHttpHeaderArray.h 2001/09/17 22:34:44 @@ -24,8 +24,8 @@ #ifndef nsHttpHeaderArray_h__ #define nsHttpHeaderArray_h__ -#include "nsVoidArray.h" #include "nsIHttpChannel.h" +#include "nsVoidArray.h" ? /be
Need to comment on the changes outside of xpcom/base...... okay, so there are two things which are broken or which are just the way they are. First, I removed nsDebug.h from nscore.h. This is so that I can freeze nscore.h, and ship it to a customer without having to drag along nsDebug. The result of this is that clients that include nscore.h without including nsDebug.h will be busted. In the case that you pointed out, I just want to make sure that the #include "nsISupports.h" that is caused by the include of an "nsI*" preceeds any other includes. If you reverse these, you will get a compilation error. The other breakage is that things like NS_IMPL_THREADSAFE_ISUPPORTS(nsFoo, NS_GET_IID(nsIFoo)); Don't seam to work with my changes. I fixed the callers that do this in the tree bug still have to figure out why this is broken. The changes which I attached shouldn't be that different once this problem is resolved (please review anyways... there is a lot here).
A few minor comments after glancing at the changes: What change broke including nsVoidArray.h before nsISupports.h? Can't you fix nsVoidArray.h? Any chance of fixing those comments mentioning "COM's nsIUnknown"? Should the debugging tricks that you put in nsISupportsObsolete.h move to nsDebug.h instead? Or should they be obsolete? Why remove the comment about the |NS_IF_ADDREF(*result = mThing);| pattern? There's still a comment mentioning NS_IMPL_QUERY_INTERFACE in nsISupportsImpl.h, even though it's moved to nsISupportsObsolete.h (it's almost ready to be removed -- see bug 45797). You also didn't move NS_IMPL_ISUPPORTS, which uses it. It would also be nice to see NS_IMPL_ISUPPORTS_INHERITED and NS_IMPL_QUERYINTERFACE_INHERITED go away in favor of the variants with 1 on them -- perhaps they should be in nsISupportsObsolete.h as well (although they still have a few more callers)?
dougt: the problem that made you move nsVoidArray.h's include from before to after nsI*.h #includes in .cpp files is that nsVoidArray.h fails to nest an include of nsCom.h. Let's fix that, and beware moving #include order around to paper over prerequisite include failures on the part of .h files. /be
>> What change broke including nsVoidArray.h before nsISupports.h? Can't you fix nsVoidArray.h? what brendan said. right. I will fix it. >> Any chance of fixing those comments mentioning "COM's nsIUnknown"? Why? >> Should the debugging tricks that you put in nsISupportsObsolete.h move to nsDebug.h instead? Or should they be obsolete? Those should be obsolteted. The proper way to declare that a component is threadsafe is through the nsIClassInfo, not some IID. > Why remove the comment about the |NS_IF_ADDREF(*result = mThing);| pattern? Mistake. I replaced it. >> There's still a comment mentioning NS_IMPL_QUERY_INTERFACE in nsISupportsImpl.h, even though it's moved to nsISupportsObsolete.h (it's almost ready to be removed -- see bug 45797). I don't think that this matters. > You also didn't move NS_IMPL_ISUPPORTS, which uses it. I don;t understand. You think that NS_IMPL_ISUPPORTS should be in the obsolete file? > It would also be nice to see NS_IMPL_ISUPPORTS_INHERITED and NS_IMPL_QUERYINTERFACE_INHERITED go away in favor of the variants with 1 on them -- perhaps they should be in nsISupportsObsolete.h as well (although they still have a few more callers)? I am not sure that this should be obsoleted yet. Lets figure out what to do with IMPL_ISUPPORTS and the INHERITED stuff and I will pop another patch.
> > You also didn't move NS_IMPL_ISUPPORTS, which uses it. > > I don;t understand. You think that NS_IMPL_ISUPPORTS should be in the obsolete > file? Yes. There are currently no users in the mozilla tree and 6 in the NS commercial tree, which I intend to fix. See bug 45797. The reason NS_IMPL_QUERY_INTERFACE is deprecated also applies to other macros that use it (I assume it's because the code to which it expands will compile even if the class inherits from the interface and it's not as general as the code used in the numbered macros, and perhaps also the NS_GET_IID required for each interface).
> >> Any chance of fixing those comments mentioning "COM's nsIUnknown"? > Why? COM doesn't use the "ns" prefix: you mean "IUnknown". I'm really digging this cleanup so far -- great work, all.
the only thing that last patch is missing which I just added is the @status line for nsISupports.idl and nsrootidl.idl. Do we what to mark the header files with this @status flag?
Why do we need the nsCom.h wrapper around nscore.h? Can we just ditch nsCom.h completely?
It is to prevent us sprinkling #include love everywhere. The list is not too bad in the mozilla tree. no idea about outside developers using this file. http://lxr.mozilla.org/seamonkey/search?string=%22nsCom.h%22
Target Milestone: --- → mozilla1.0
Comment on attachment 50697 [details] [diff] [review] more changes by rick sr=rpotts@netscape.com
Attachment #50697 - Flags: superreview+
i think that we should land this *huge* patch and start polishing it with smaller patches. Assuming that everyone agrees that these gross changes are in the right direction. -- rick
I was smoking some crack when I put together the license on the new files. I will replace the crap I have in the patch with the triple moz license.
Attachment #50697 - Flags: review+
I just landed the last patch on the trunk. Are there any additional immediate tasks which we missed, or is this bug ready to be closed?
I think we're good to close.
I posted an overview of what we did to the xpcom ng. marking fixed. If regressions pop up, please open a new bug.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: