332457 - Reorganize /mozilla/calendar

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Matthew (lilmatt) Willis]

In addition to moving the l10n stuff out of /m/cal/resources/locale (bug 267981) we should reorganize the rest of the calendar directory structure to better handle the building of multiple apps/extensions (Sunbird, Lightning, CalXPI) from within it.

mvl wrote about part of the problem at
http://wiki.mozilla.org/Calendar:Build_System

I'll attach my suggested layout.
It fits with the strategy of the folks handling our move to /l10n

I'm not sure everyone that is required to r/sr? this thing, but please give me any suggestions.

We'll want to do some moving outside of CVS in order to keep history, but some items (ex: /m/cal/windows) probably don't need their history saved.

Comment 1

[Matthew (lilmatt) Willis]

Attachment: My proposed new directory layout

Comment 2

[Robert Kaiser]

I added my comments to the proposed layout in http://wiki.mozilla.org/Calendar_Talk:Build_System#Comments

Basically, http://wiki.mozilla.org/SeaMonkey:Suite_Directory_Layout#.5B2006-01-17_07:00_PST.5D_-_topic:_suite.2F_organization is worth a read (a discussion with bsmedberg about how to organize the mozilla/suite/ directory, including some general advice about how to structure an app's dir in the mozilla.org repository).

The biggest rule bsmedberg hands out for the mozilla.org repository:
'organize things according to function, not according to "how it's built"'

That means "components/", "resources/", "extensions/", etc. are really bad names and should be faded out, for sure not newly created.
The only kind-of-exception to that is "locales/", as all localizeable content should go into that (at least if you want to enable the new source-based L10n approach, see bug 267981).

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

We should only move directories and files if there is a good reason for it. We schould evaluate each move that way. Moving 'just because' isn't a good plan.

With that in mind:
Why move sunbird/app? Sunbird is one of the frontends we offer. As such, it should  live in calendar/sunbird. I don't see a reason to move it. (same goes for the moving of all other subdirs of the old sunbird dir.)

Comment 4

[Matthew (lilmatt) Willis]

(In reply to comment #3)
> We should only move directories and files if there is a good reason for it. We
> schould evaluate each move that way. Moving 'just because' isn't a good plan.

Agreed.
We know that CVS makes it non-trivial to move and maintain history, and moving
code will force us to "relearn" where some stuff lives.

Why I feel this isn't "just because"...

In http://wiki.mozilla.org/Calendar:Build_System you outlined a couple ways
to address our build silliness. I feel the last one (two flavours: fullwindow
and lightning) is the most appropriate.

I feel reducing the number of variations of calendar we release and support
is critical to our success in shipping a _really_ useable app. We don't have
devs or QA folk coming out our ears to assign "go make sure all these changes
don't bust the xpi on Seamonkey". As a result, I don't think it makes sense
for us to continue to develop, release, and support the xpi as it stands. (If
we could figure out a way to basically make Sunbird be an xpi that Xulrunner
runs, and _that_ would run on Seamonkey once they move to toolkit, then we
could consider other options.)

If we assume the above to be true (which is not necessarily a forgone
conclusion), then I'm proposing we migrate towards the layout that Ff and Tb
are using, if only for similarity between the projects when devs are trying
to track down bugs and understand what code does what where. (Example: If
mscott had to find a bug in lightning, would he know where to look given the
current tree layout? Can we eliminate, or lessen this "learning curve" for
others to become involved?)

I was trying to model the tree based on Ff and Tb, and keep a special spot for
lightning, since it shares so much code already. We have already begun to move
some of Sunbird's bits out of /m/cal/sunbird. I'm simply suggesting we finish
the process, and finally move the xpi's bits out of the way.

Examples: 
    /m/cal/locales/en-US/chrome/branding is entirely for Sunbird
    Common theme elements for both lightning and Sunbird are now in /m/cal/base/themes


For what it's worth, this is exactly the discussion I wanted to open up with this proposal.

Comment 5

[Joey Minta]

(In reply to comment #4)
> If we assume the above to be true (which is not necessarily a forgone
> conclusion), then I'm proposing we migrate towards the layout that Ff and Tb
> are using, if only for similarity between the projects when devs are trying
> to track down bugs and understand what code does what where. (Example: If
> mscott had to find a bug in lightning, would he know where to look given the
> current tree layout? Can we eliminate, or lessen this "learning curve" for
> others to become involved?)
I think this is an important point to keep in mind.  However, I'm not entirely sure that moving things around cvs is the proper way to solve it.  As long as there is good clear documentation about where to find things, that's the quickest way to shorten the learning curve.  It's a large part of the motivation why I started (but didn't finish) writing http://wiki.mozilla.org/Calendar:Dev_Guide

Note that kairo/bsmedberg's point about organizing things based on function also factors into this problem.  If you group things by function, and people know they're grouped by function, then things are also easy to find.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

If we really want to mimic the thunderbird structure, we would need a nwe top-leve dir 'sunbird. But we can't (and don't want) to do that. The closest we can get is a calendar/sunbird dir, and the app dir inside that. I don't think that somebody who want to start ahcking sunbird won't be able to guess that the dir called 'sunbird' might contain, ehm, sunbird.

Also, note that the wiki document was written about a year ago. Since then, we learned a lot, and with the current tweaks, building mostly work. I agree that we want to reduce the number of different front-ends, and I think we can do that by dropping the xpfe-based version in favour of the sunbird xul files.

I think that the sunbird-specific things should stay in m/cal/sunbird, and the shared front-end files can live in m/base/content.

In short: I don't see any sillyness in the current build system. It works, so why change it?

Comment 7

[Matthew (lilmatt) Willis]

(In reply to comment #6)
> If we really want to mimic the thunderbird structure, we would need a nwe
> top-leve dir 'sunbird. But we can't (and don't want) to do that.

I disagree. There is not top level directory "Thunderbird".
    Firefox     = /mozilla/browser
    Thunderbird = /mozilla/mail
    Sunbird     = /mozilla/calendar (with lightning inside)

> I agree that we want to reduce the number of different front-ends, and I
> think we can do that by dropping the xpfe-based version in favour of the
> sunbird xul files.

Agreed. Let's be sure dropping xpfe is one of the first things addressed at this week's meeting.

> In short: I don't see any sillyness in the current build system. It works, so
> why change it?

In chatting with dmose last night, we discussed whether the effort to handle a complete shuffle of the code would be better put towards other things. This probably is true. Perhaps the more appropriate outcome of this bug would be to define a "roadmap" as to where stuff should go in a future perfect world, and follow that when it makes sense to move something out from under /m/cal/sunbird (for example, themes was identified as worthy of expending effort for moving) or when creating something new.

I also would like to clean out the xpfe xpi's cruft (the platform named folders with only icons inside) from the top level directory, so I'll put together a patch for removing that stuff.

Comment 8

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #7)
>     Sunbird     = /mozilla/calendar (with lightning inside)

That last point is my problem. Why is lightning living below sunbird? lightning is no part of sunbird. It's a front-end, that lives on the same level. To show that, they should be in directories next to each other, just like they currently are.
And for learning the directories, moving them will save maybe 10 seconds of somebody trying to find out where the files are. It won't be too hard to guess that the sunbird dir holds sunbird code, even if it isn't an exact duplicate of the firefox dir structure.

> I also would like to clean out the xpfe xpi's cruft (the platform named folders
> with only icons inside) from the top level directory, so I'll put together a
> patch for removing that stuff.
> 
Yes, agreed with that. There are some (mostly small) directories that need to move.

Comment 9

[Matthew (lilmatt) Willis]

Attachment: Deletes SeaMonkey xpi icons

Comment 10

[Matthew (lilmatt) Willis]

Attachment: Revised layout

Comment 11

[Joey Minta]

Comment on attachment 217079 [details] [diff] [review]
Deletes SeaMonkey xpi icons

mvl is mr. seamonkey for us.  And I really don't want to be the reviewer for the first death-blow to calendar-in-seamonkey.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

mozilla
    calendar
        base
            build
            content     <-- dir merged with /m/cal/sunbird/base/content

What does the above sentence mean?

Comment 13

[Matthew (lilmatt) Willis]

Attachment: Revised revised layout

(In reply to comment #12)
> What does the above sentence mean?

It means I bozoed it and left an old line in there.
Stuff that Sunbird and Lightning share should live there.
New proofread version attached.

Comment 14

[Matthew (lilmatt) Willis]

Attachment: moves all xpi icons beneath /m/cal/xpi, removes reference to xpi in calendar's Makefile.in

This doesn't delete the icons, but just moves them beneath xpi/

Comment 15

[Matthew (lilmatt) Willis]

Attachment: just moves xpi icons beneath /m/cal/xpi

Comment 16

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 225986 [details] [diff] [review]
just moves xpi icons beneath /m/cal/xpi

Doesn't this need a Makefile.in change, or something else changed in the packaging/build system?

Comment 17

[Matthew (lilmatt) Willis]

(In reply to comment #16)
> (From update of attachment 225986 [details] [diff] [review] [edit])
> Doesn't this need a Makefile.in change, or something else changed in the
> packaging/build system?

Not that I could find. It appears this stuff hasn't been used in quite some time.

Comment 18

[Michiel van Leeuwen (email: mvl+moz@)]

http://lxr.mozilla.org/seamonkey/search?string=calendar-window indicates that the icons are still referenced from some obscure places, but are indeed not packaged...

Comment 19

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 225986 [details] [diff] [review]
just moves xpi icons beneath /m/cal/xpi

r=mvl

Comment 20

[Matthew (lilmatt) Willis]

patch checked in on branch and trunk

Comment 21

[Matthew (lilmatt) Willis]

Not going to make the 0.3 train.

Comment 22

[Matthew (lilmatt) Willis]

The only major items left for this bug from my perspective are:
- unifying of themes directories where possible
- gradual removal of /m/cal/resources

The former will require discussion in the post-0.3 release timeframe.
It should be done to reduce duplication and simplify theme development by others.

The latter is already in progress, and from the perspective of folks like mvl (and now amazingly, myself), we don't gain a lot wasting cycles just making the build environment pretty while we've got lots of user-facing bugs to deal with. It should happen when it can, and when it makes sense.

Since we haven't all agreed on migrating to a common "themes" directory, I don't want to hold the bug open waiting on that.

-> FIXED