Closed Bug 332457 Opened 14 years ago Closed 14 years ago
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.
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).
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.)
(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.
(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.
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?
(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.
(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.
Attachment #217079 - Flags: first-review?(jminta)
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.
Attachment #217079 - Flags: first-review?(jminta) → first-review?(mvl)
mozilla calendar base build content <-- dir merged with /m/cal/sunbird/base/content What does the above sentence mean?
(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.
Attachment #217081 - Attachment is obsolete: true
This doesn't delete the icons, but just moves them beneath xpi/
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?
(In reply to comment #16) > (From update of attachment 225986 [details] [diff] [review] ) > 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.
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 on attachment 225986 [details] [diff] [review] just moves xpi icons beneath /m/cal/xpi r=mvl
Attachment #225986 - Flags: first-review?(mvl) → first-review+
patch checked in on branch and trunk
Not going to make the 0.3 train.
Target Milestone: Sunbird 0.3 → Sunbird 0.4
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
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.