374697 - Add XUL Explorer project to a Mozilla repository

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

XUL Explorer is a XUL development, exploration and learning tool. I have had a few patches and many requests to assist with coding sent to me.

It would be much easier to just setup the code in a public repository. I don't know which repository (CVS or SVN) would be best suited to host. I am also not sure how the module ownership comes into play either.

Comment 1

[Reed Loden [:reed]]

The "thing to do" nowadays is to just put it in Subversion. That's where all the labs projects are, where joey is, etc.

Comment 2

[Dave Miller [:justdave]]

Thank you for that enlightenment.

This needs to be approved by Brendan, I believe, as it's an external project that's requesting us to put it under our umbrella.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #2)
> 
> This needs to be approved by Brendan, I believe, as it's an external project
> that's requesting us to put it under our umbrella.
> 

I am totally fine with getting any and all approvals, but as a Mozilla employee (I know bugmail is to gmail), this project can be considered an internal project. And if there is some reason that it isn't considered internal, we can make it internal.

Comment 4

[Dave Miller [:justdave]]

oh, schrep (or shaver, who you already had CCed) instead of brendan then. :)

Pretty much a given in that case, just need to be told where to put it. :)

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #4)

> Pretty much a given in that case, just need to be told where to put it. :)
> 

Word from shaver is: SVN, projects/xul-explorer

I have limited CVS access, but what do I need for SVN access?
Also note that I do have issues with my CVS checkins. See bug 370161

Comment 6

[Reed Loden [:reed]]

(In reply to comment #5)
> (In reply to comment #4)
> > Pretty much a given in that case, just need to be told where to put it. :)
> Word from shaver is: SVN, projects/xul-explorer

Has preed ok'd this location? The projects/ directory is currently all web-based stuff (websites, planet.m.o, cms, etc.), which this doesn't seem to match. I would think a new directory in the root for projects such as this (you mentioned "devrel") would be better, but that's just my opinion.

> I have limited CVS access, but what do I need for SVN access?

Morphing bug into an SVN Account Request.

Comment 7

[Mike Shaver (:shaver emeritus)]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Pretty much a given in that case, just need to be told where to put it. :)
> > Word from shaver is: SVN, projects/xul-explorer
> 
> Has preed ok'd this location? The projects/ directory is currently all
> web-based stuff (websites, planet.m.o, cms, etc.), which this doesn't seem to
> match. I would think a new directory in the root for projects such as this (you
> mentioned "devrel") would be better, but that's just my opinion.

If projects/ was just for web stuff, it should have been named that way.  "Projects such as this" might be something like "tools", but it won't be "devrel" -- the org chart section from which the code originated isn't relevant for source tree organization.  What do you mean by "projects such as this", that should unify locations in the source tree?

Believe me, I'm not a fan of the "projects" prefix, since I think it doesn't carry any value, but I didn't think that just asking for the (to me obviously clearer and superior) "/xul-explorer" location would be productive given history.

Can you unmorph this unresolved bug about location of the source, please?  If a new bug is needed for an SVN request, it should be filed separately rather than losing the unfixedness of the location discussion when the SVN account is created, etc.

Comment 8

[J. Paul Reed [:preed]]

(In reply to comment #7)

> Believe me, I'm not a fan of the "projects" prefix, since I think it doesn't
> carry any value, but I didn't think that just asking for the (to me obviously
> clearer and superior) "/xul-explorer" location would be productive given
> history.

Sigh. We go through this every time SVN comes up.

The "projects" prefix made more sense when we thought we were going to put mozilla/ into svn, but having a few top level directories makes more sense than throwing everything into the top level (then you have a repeat of mozilla/ in CVS, where there's no organization at all, and we spend a bunch of time trying to figure out what's relevant to the browser, and what's not. But I digress.)

And the projects prefix isn't just for webstuff. I believe it just turned out that way.

Anyway, is this a Mozilla labs project?

If it is, put it in labs/xul-explorer.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #8)
> And the projects prefix isn't just for webstuff. I believe it just turned out
> that way.
> 
> Anyway, is this a Mozilla labs project?
> 
> If it is, put it in labs/xul-explorer.
> 

Not a labs project. Sounds like projects/xul-explorer is our best candidate.

Comment 10

[Mike Shaver (:shaver emeritus)]

No, it's not a Labs project.  It's just a tool that needs a repository location for collaboration and distribution of source.

(Not that I understand labs/ really, because when stuff evolves to the point of being production-ready you will have to move it out of that area, but it doesn't affect me here because I'm not in labs..)

Do you object to projects/xul-explorer?  I'm OK with it, and it sounds like projects/ isn't intended to be just for web stuff, so let's go?

(Things become relevant to the browser and irrelevant to the browser over time, so I'm not sure that reflecting that in the hierarchy would be helpful.  Flatter hierarchies tend to win in those cases because the nature of a chunk of code tends to change much less frequently than its relationship to a given product.)

Comment 11

[J. Paul Reed [:preed]]

(In reply to comment #9)

> Not a labs project. Sounds like projects/xul-explorer is our best candidate.

Alright... then other-quick-question: why can't/shouldn't this go into CVS? If it's related to the browser, and is dependent on interfaces in the browser, it should really be with the browser code.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #11)

> Alright... then other-quick-question: why can't/shouldn't this go into CVS? If
> it's related to the browser, and is dependent on interfaces in the browser, it
> should really be with the browser code.
> 

Its a standalone XUL development tool built on XULRunner.

I think comment #10 parenthetical on browser relation was in general and not specific to this project.

Comment 13

[Mike Shaver (:shaver emeritus)]

It's not dependent on interfaces in the browser, it's a standalone application.  Regardless, I don't want to put new code in CVS, because CVS sucks -- same reason that operator isn't in CVS, though it's much more closely tied to the browser internals than we are.

Comment 14

[J. Paul Reed [:preed]]

K, then I guess projects/xul-explorer it is.

Are you going to do the standard trunk/ directory under it, as well?

I can create that for you, and then we can get the right permissions in place for it.

Comment 15

[Mike Shaver (:shaver emeritus)]

Yep, I have every intent of following our SVN layout policies! :)

Since Reed didn't unmorph this, I'm going to undo his damage here as well.  Mark: please file for an SVN account, cc: me?

Comment 16

[Mike Shaver (:shaver emeritus)]

preed: any ETA on having the space created?  We have some interest in discussing, and hopefully working on, XUL Explorer at the upcoming developer days, plus other interested contributors for whom I'd like to be able to set expectations.

And please let me know if there's anything I can or should do to expedite or otherwise make this smoother.

Comment 17

[J. Paul Reed [:preed]]

(In reply to comment #16)
> preed: any ETA on having the space created?  We have some interest in
> discussing, and hopefully working on, XUL Explorer at the upcoming developer
> days, plus other interested contributors for whom I'd like to be able to set
> expectations.

Oh, I can do that today (at the Developer Day).

This is my bad; I thought I was waiting on you, and you were gonna ping me in IRC, and we'd just do it that way.

Sorry about that.

We'll have to get IT to update the authorization file, too, so the appropriate people have checkin privs to that area.

Comment 18

[J. Paul Reed [:preed]]

svn.mozilla.org/projects/xul-explorer added at rev. 2925.

Comment 19

[J. Paul Reed [:preed]]

Added trunk/ and tags/, too.

Comment 20

[Mike Shaver (:shaver emeritus)]

FIXED, you rule and stuff.