Difference between revisions of "Status Meetings:2006-10-04:Agenda"
Jump to navigation
Jump to search
(→General Plans: some more thoughts) |
|||
| Line 7: | Line 7: | ||
** Funky select widgets, missing trunk talkback are out of our hands | ** Funky select widgets, missing trunk talkback are out of our hands | ||
** How can we improve? The problems will only increase as xpfe dies.... | ** How can we improve? The problems will only increase as xpfe dies.... | ||
| − | * What about putting l10ns into Camino source repository? (by Marcello) | + | * What about putting l10ns into Camino source repository? (by [[User:Marcello|Marcello]]) |
| − | ** I'd like to spend most of my efforts on the community side of Caminol10n, trying to make it better and more productive. Since I already | + | ** I'd like to spend most of my efforts on the community side of Caminol10n, trying to make it better and more productive. Since I already maintain (in a very clumsy way) a cvs repository of l10n packages and text files, why not put them among Camino's source, so that the ML package might be built directly from that place? |
| − | ** Pros: I shouldn't work on building and distributing, and I would not be a bottleneck as sometimes happened in the past | + | ** Pros: |
| − | ** Cons: The build system | + | ***I shouldn't work on building and distributing, and I would not be a bottleneck as sometimes happened in the past |
| + | *** ''Unified Camino build more in line with Mac OS X'' | ||
| + | ** Cons: | ||
| + | *** The build system would need be changed | ||
| + | *** ''Moving the bottleneck to coordinating cvs checkins'' | ||
| + | *** ''Out-of-date translations:'' | ||
| + | **** ''Stale files on development branches (e.g., an out-of-date BrowserWindow.nib will hork that language) [could be worked around by keeping nightlies En-only]'' | ||
| + | **** ''Non-updated l10ns still in cvs across branch changes or emergency new strings on a stable branch (e.g., Pirate 1.0.x never gets updated for 1.x, or in the event string changes are needed for 1.0.x+1)'' | ||
| + | *: ''additional pros/cons in italics by [[User:sardisson|sardisson]], who'd really like to see a unified Camino build nonetheless'' | ||
==Specific bugs that need action== | ==Specific bugs that need action== | ||
Revision as of 13:49, 25 September 2006
Wed 04 Oct 9am PDT (16:00 GMT/UTC) in #camino-mtg
General Plans
- Camino 1.1 Alpha 1
- Fixing Core-caused breakage in Camino in a timely fashion
- Time it took to get biesi's patch (super)reviewed [4 days], to get autocomplete fix (super)reviewed, to get chardet fix (super)reviewed
- Funky select widgets, missing trunk talkback are out of our hands
- How can we improve? The problems will only increase as xpfe dies....
- What about putting l10ns into Camino source repository? (by Marcello)
- I'd like to spend most of my efforts on the community side of Caminol10n, trying to make it better and more productive. Since I already maintain (in a very clumsy way) a cvs repository of l10n packages and text files, why not put them among Camino's source, so that the ML package might be built directly from that place?
- Pros:
- I shouldn't work on building and distributing, and I would not be a bottleneck as sometimes happened in the past
- Unified Camino build more in line with Mac OS X
- Cons:
- The build system would need be changed
- Moving the bottleneck to coordinating cvs checkins
- Out-of-date translations:
- Stale files on development branches (e.g., an out-of-date BrowserWindow.nib will hork that language) [could be worked around by keeping nightlies En-only]
- Non-updated l10ns still in cvs across branch changes or emergency new strings on a stable branch (e.g., Pirate 1.0.x never gets updated for 1.x, or in the event string changes are needed for 1.0.x+1)
- additional pros/cons in italics by sardisson, who'd really like to see a unified Camino build nonetheless
Specific bugs that need action
Queries
- Bugs targeted at 1.1
- Blocking ?
- Blocking +
- Blocking -
- Bugs without target
- The above list needs to be at least spot-audited for potential 1.1 issues