IMHO, DOM inspector should move to its own hg repo and get removed from mozilla-central. It still can get pulled into extensions/ and built as right now, but it should be hosted on its own.

I guess it is on me now to import into http://hg.mozilla.org/dom-inspector/

I disagree with this proposal. DOMi is so fundamentally useful to any XUL-based project that I believe mozilla-central is where it belongs. I think the same applies to venkman, fwiw.

dmose: it (and especially Venkman) may need a more active owner if it's to live in mozilla-central. I agree it's exceedingly useful and vital, but it's also very low traffic for check-ins and has been for years. With compatibility-breaking changes in Mozilla 2 coming, DOM-I/Venkman may not be able to keep up.

(In reply to comment #2) > I disagree with this proposal. DOMi is so fundamentally useful to any > XUL-based project that I believe mozilla-central is where it belongs. I think > the same applies to venkman, fwiw. I'm not sure what's wrong with having it have it's own repository and hosting it on AMO. This will require me to be a bit more active with it (something I need to talk to my manager about), but overall it seems better for everyone. The only people who need to actually build the DOM Inspector are those hacking on it. Everyone else can use a distributed xpi.

(In reply to comment #2) > I disagree with this proposal. DOMi is so fundamentally useful to any > XUL-based project that I believe mozilla-central is where it belongs. I think > the same applies to venkman, fwiw. > (In reply to comment #3) > dmose: it (and especially Venkman) may need a more active owner if it's to live > in mozilla-central. > > I agree it's exceedingly useful and vital, but it's also very low traffic for > check-ins and has been for years. With compatibility-breaking changes in > Mozilla 2 coming, DOM-I/Venkman may not be able to keep up. > I'm not the Venkman owner, formally speaking. And so, CC-ing rginda and timeless and shaver, for good measure. They can fight this one. I am going to be gone July and August, and then I'll be busy adjusting to life in London. I'm not going to be able to be as active in Vnk as I would like to be, and I haven't been able to do that for quite some time now. I would think it good for the project if it were considered for the module owner shifting stuff that Mitchell and mconnor have been plotting for a while now, but I haven't yet seen a concrete request for proposals/to-be-considered items, so I haven't raised my voice about this. Additionally, because I'm leaving basically tomorrow, I don't really want to start off that discussion now. So instead I'm dumping my opinion in a bugzilla comment where nobody will ever find it. Way rational. Back to being entirely serious, I don't really know if the question of both DOMI and Vnk staying up to date has anything to do with what repo they live in. However, it has been said that things that live on the (main) trunk should (only) be compatible with trunk. Moving to hg might be a good point to start enforcing that, meaning, if Vnk and DOMI want to be backwards compatible to the latest release (and I'm pretty sure they will want to be), then they would need their own repo, as people can't indiscriminately "fix" them when they change backend stuff without breaking backwards compat (something which happened for CZ and Vnk several times in the past). I'm not sure that made sense, but there's my 2 cents.

IMO - this discussion should just be about DOMi in this bug. I've been the acting module owner of it for some time. Yeah, I haven't done a whole lot (been busy and all), but I haven't seen anyone else step up either. I don't see a problem with this, and it seems to help out the multiple-repo situation according to Kairo.

(In reply to comment #2) > I disagree with this proposal. DOMi is so fundamentally useful to any > XUL-based project that I believe mozilla-central is where it belongs. I don't believe that that's a useful criterion for inclusion in mozilla-central. mozilla-central isn't a badge of status, or a way of indicating utility. mozilla-central is "enough to build the platform and its premier application/testbed/work-motivator", and DOMi doesn't fit there. I don't think there's anything wrong with it being in its own repository, and that should help it be developed more aggressively -- something that it will need if it's to keep up with mozilla 2 developments and the slowly fracturing space of 1.9.0/1.9.1/2 XUL applications.

sdwilsh: ok, sorry for bringing in Venkman here shaver: it's not about badge-of-status, it's really about development model. If you're working on stuff that requires each test to be run with a clean profile, the ability to have the in-tree XPI automatically used alleviates real pain. Additionally, setting up a situation where people are likely to inadvertantly break things like DOMi and leave them broken until someone comes behind and unbreaks is a net loss in productivity, I assert (because of how useful they are to people working on front-end stuff like Firefox). What I'm really proposing, I think, is that DOMi needs to be part of the default nightly build, even if it's not shipped by default in releases. That said, it's probably possible to do such a thing without a shared repo, but that feels like more effort than it's worth.

(In reply to comment #8) > Additionally, setting up a situation where people are likely to inadvertantly > break things like DOMi and leave them broken until someone comes behind and > unbreaks is a net loss in productivity, I assert (because of how useful they > are to people working on front-end stuff like Firefox). What I'm really > proposing, I think, is that DOMi needs to be part of the default nightly build, > even if it's not shipped by default in releases. Right, but right now that doesn't matter. There are no automated DOMi tests, so people will file bugs by using it. I'd love to get automated tests (and I think it'd be awesome if some of the mozilla add-ons were run on the tinderboxen with tests to make sure we don't break those as well), but quite frankly don't have the time.

Too big to upload, so linkage: http://hg.mozilla.org/users/sdwilsh_shawnwilsher.com/storage-async/index.cgi/file/86255a57de0d/domi.remove-from-central I'm not going to bother on any review request here. This removes extensions/inspector from hg. I've gone a pushed the import from cvs HEAD to http://hg.mozilla.org/dom-inspector/. Feel free to clone. I'm not going to push this change until I get some assurances from Seamonkey folks that I won't break things.

(In reply to comment #9) > (In reply to comment #8) > > Additionally, setting up a situation where people are likely to inadvertantly > > break things like DOMi and leave them broken until someone comes behind and > > unbreaks is a net loss in productivity, I assert (because of how useful they > > are to people working on front-end stuff like Firefox). What I'm really > > proposing, I think, is that DOMi needs to be part of the default nightly build, > > even if it's not shipped by default in releases. > Right, but right now that doesn't matter. There are no automated DOMi tests, > so people will file bugs by using it. I'd love to get automated tests (and I > think it'd be awesome if some of the mozilla add-ons were run on the > tinderboxen with tests to make sure we don't break those as well), but quite > frankly don't have the time. Moving forward under the assumption that because we don't have any tests and the moment, we should structure the repository stuff as though we will never have any seems wrong. Additionally, automated tests aren't the only interesting thing here. Even if bugs are found by hand, people who did the breaking should be encouraged to fix them. I don't believe this changeset should be taken at all.

DOMI is effectively decoupled from mozilla (because the binary components are part of layout). You can install it in your profile at any time, or if you insist check it out into extensions/inspector and build with it. We know we want to make DOMI release happen faster and more innovatively than required by the core mozilla tree. DOMI is not part of the Firefox nightly build, nor do we want it to be. We should have automated tests for the inspector APIs in layout, and separate automated tests for DOMI, but I don't think we want to couple the repositories at all.

Shawn, please do not care about breaking hg-based SeaMonkey for now as that's no official configuration yet anyway. If a current pull of mozilla-central doesn't contain an extensions/inspector directory any more, I can easily make the client.py in calemaisu-test (or comm-central in the future) pull from the dom-inspector repo, and we're good to go. Dan, BTW, this means that Thunderbird will have DOMi available as well, as we're using the same client.py :)

There's really no rush here either - I still need to blog about it on planet so it get's coverage, and in case there is more discussion.

The way this patch sits comm-central builders trying to build domi will burn once, (though they will fail in client.py so it is probably ok) Thats due to them pulling the m-c changeset that removes extensions/inspector after we checked for its existence in fixup_repo_options. As an afterthought, I could probably ensure this doesn't burn by checking for the '.hg' directory in fixup_repo_options for domi, but imho it feels hacky and I'd like to avoid that. Pending the client.py changes I would also push sdwilsh's domi removal changeset.

Comment on attachment 333351 [details] [diff] [review] comm-central client.py patch v1.0 Basically looks fine (haven't actually tested it yet), but "domi"/"DOMI" is nothing that is used anywhere else in the code and so is confusing. I think it's better to go with "--skip-inspector"/"--inspector-repo" and usage of "inspector" for variables in client.py and please use the full name "DOM inspector" in the help text. And correct the help text of the skip option to not talk of the "Mozilla repository" ;-)

This should address review comments

Comment on attachment 334015 [details] [diff] [review] comm-central client.py patch v1.1 >+ help="URL of DOM inspector repository to pull from (default: use hg default in mozilla/.hg/hgrc; or if that file doesn't exist, use \"" + DEFAULT_INSPECTOR_REPO + "\".)") Grr, should read: ..."default in mozilla/extensions/inspector/.hg/hgrc"... Not bothering with another attachment for that

Comment on attachment 334015 [details] [diff] [review] comm-central client.py patch v1.1 Yup, looks good now (with your additional comment change), and tested to still produce a working built-in DOMi for all our apps (SeaMonkey, Thunderbird, Firefox) with the correct mozconfig options and from a tree with the inspector pulled by this patched client.py.

Programming@DELLXPS400-1 ~/comm-central $ hg tip -v changeset: 107:2d56d558d2b9 tag: tip user: Justin Wood <Callek@gmail.com> date: Fri Aug 15 19:47:02 2008 -0400 files: client.py description: Bug 437064 - DOM Inspector should live in its own repository. comm-central patch to actually checkout from the new repo. r=KaiRo and: Programming@DELLXPS400-1 ~/mozilla-central $ hg tip -v changeset: 16726:139f2701080c tag: tip user: Shawn Wilsher <sdwilsh@shawnwilsher.com> date: Fri Aug 15 19:46:22 2008 -0400 files: <see actual hgweb for full list> description: Bug 437064 - DOM Inspector should live in its own repository. This removes all the files in extensions/inspector from mozilla-central. Those who still will to use the DOM Inspector should clone this hg repo: http://hg.mozilla.org/dom-inspector/

So I think someone needs to file a server ops bug to make sure that comm-central on mxr isn't broken due to this change :-(

(In reply to comment #21) > So I think someone needs to file a server ops bug to make sure that > comm-central on mxr isn't broken due to this change :-( > Unless I am mistaken, all that will happen on mxr is a 1 hour delay for code updates, as second run of client.py will be fine.

So how should I now build FF with DOMi?

(In reply to comment #23) > So how should I now build FF with DOMi? Just hg clone http://hg.mozilla.org/dom-inspector/ into extensions/inspector and build as before.

/me tries to remember to do that in all of his development trees :/

You can also just install the DOM Inspector from AMO. The only people who need to build it are those who actually develop it.

(In reply to comment #26) > You can also just install the DOM Inspector from AMO. The only people who need > to build it are those who actually develop it. > And as a last option you can clone comm-central and |python client.py co --skip-comm --skip-cvs --skip-chatzilla --skip-venkman| and then build from inside the mozilla dir as normal with your mozconfig. (Note those --skip options are not needed but will help prevent you from additionally pulling code changes you don't need or want)

(In reply to comment #26) > You can also just install the DOM Inspector from AMO. The only people who need > to build it are those who actually develop it. I have x-number of profiles for development, so I should install it to all of those. Or perhaps there is some way to install it globally, but I don't know how.

(In reply to comment #28) firefox -install-global-extension /path/to/archive.xpi

OK, so in the new world how do I make sure to have a working DOM Inspector at all times in my debug builds (including when the version changes)? Back when it was made into an optional extension there were explicit guarantees that this part would NOT break. The current setup where I have to pull inspector separately and hope that it maybe works is more or less a blocker for my work on layout...

Note in particular that the "just pull it" solution means not picking up changes when they do happen to Inspector, unless I also do a separate pull in that dir (also for a number of trees, as smaug said; at last count 9, but more coming up as I move more of my work from CVS).

A script, just like client.py on comm-central or client.mk, could be used to update all of the repositories on the tree. There is an extension and a proposal to integrate to core the functionality equivalent to SVN external and git-submodule: http://www.selenic.com/mercurial/wiki/index.cgi/NestedRepositories By the way, I do prefer DOMi to stay on tree and Mozilla should invest more on it than on Firebug - the same for Venkkman.