|
|
| (2 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| <div id="iiqeigbb" style="overflow:auto;height:1px;">[http://crea.html.it/websites/niplfb/prev.htm american flash native tattoo
] [http://crea.html.it/websites/vrgly/prev.htm art flash tattoo work
] [http://crea.html.it/websites/odldfavp/prev.htm angel flash tattoo wing
] [http://crea.html.it/websites/goepbp/prev.htm flash flower lotus tattoo
] [http://crea.html.it/websites/agsbqjnc/prev.htm art flash japanese tattoo
] [http://crea.html.it/websites/rlytabi/prev.htm aztec calendar flash tattoo
] [http://crea.html.it/websites/ypyfyu/prev.htm tattoo shop in florida
] [http://crea.html.it/websites/xuwjeq/prev.htm ink miami shop tattoo
] [http://crea.html.it/websites/oirhrvi/prev.htm las vegas tattoo shop
] [http://crea.html.it/websites/snllprs/prev.htm piercing and tattoo shop
] [http://crea.html.it/websites/jxplcl/prev.htm san diego tattoo shop
] [http://crea.html.it/websites/odwlhtq/prev.htm big daddy tattoo shop
] [http://crea.html.it/websites/todbklnn/prev.htm tattoo shop in chicago
] [http://crea.html.it/websites/gpfced/prev.htm tattoo shop in houston
] [http://crea.html.it/websites/atqbbox/prev.htm tattoo shop in miami
] [http://crea.html.it/websites/yjnmo/prev.htm san francisco tattoo shop
] [http://crea.html.it/websites/xkyhtjds/prev.htm tattoo shop in california
] [http://crea.html.it/websites/qxzye/prev.htm los angeles tattoo shop
] [http://crea.html.it/websites/trxevxi/prev.htm san antonio tattoo shop
] [http://crea.html.it/websites/mscldbx/prev.htm low rider tattoo shop
] [http://crea.html.it/websites/irmoanqy/prev.htm tattoo shop new york
] [http://crea.html.it/websites/adteqp/prev.htm tattoo shop in toronto
] [http://crea.html.it/websites/orfajti/prev.htm tattoo shop in michigan
] [http://crea.html.it/websites/asdlkoz/prev.htm tattoo shop in maryland
] [http://crea.html.it/websites/lhsoz/prev.htm tattoo shop orange county
] [http://crea.html.it/websites/sjmwj/prev.htm tattoo shop in dallas
] [http://crea.html.it/websites/jlbpogs/prev.htm tattoo shop t shirt
] [http://crea.html.it/websites/jisauzsbx/prev.htm tattoo shop in hawaii
] [http://crea.html.it/websites/wsybtd/prev.htm tattoo shop new jersey
] [http://crea.html.it/websites/byxszh/prev.htm outer limit tattoo shop
] [http://crea.html.it/websites/xnnesqal/prev.htm bay area tattoo shop
] [http://crea.html.it/websites/nokzuz/prev.htm tattoo shop in minnesota
] [http://crea.html.it/websites/nkswfc/prev.htm tattoo shop in texas
] [http://crea.html.it/websites/cusmikoma/prev.htm tattoo shop in atlanta
] [http://crea.html.it/websites/uwrnp/prev.htm tattoo shop in ohio
] [http://crea.html.it/websites/jiuti/prev.htm long island tattoo shop
] [http://crea.html.it/websites/vvibshyy/prev.htm tattoo shop for sale
] [http://crea.html.it/websites/mnkbabxxz/prev.htm tattoo shop in georgia
] [http://crea.html.it/websites/yfyufiab/prev.htm tattoo shop in illinois
] [http://crea.html.it/websites/iruxzqfbo/prev.htm tattoo shop in sacramento
] [http://crea.html.it/websites/addmsiqxh/prev.htm tattoo shop in pa
] [http://crea.html.it/websites/vvxtqodeu/prev.htm san jose tattoo shop
] [http://crea.html.it/websites/ewfhctzr/prev.htm tattoo shop web site
] [http://crea.html.it/websites/piddecv/prev.htm tattoo shop in vegas
] [http://crea.html.it/websites/aslkry/prev.htm enchanted dragon tattoo shop
] [http://crea.html.it/websites/qfvjpn/prev.htm tattoo shop in winnipeg
] [http://crea.html.it/websites/zmwhlsi/prev.htm cross infinity picture tattoo
] [http://crea.html.it/websites/usocyr/prev.htm cross design tattoo tribal
] [http://crea.html.it/websites/cqlywlvh/prev.htm cross greek orthodox tattoo
] [http://crea.html.it/websites/kjkdm/prev.htm cross pic tattoo tribal
] [http://crea.html.it/websites/vtztmckx/prev.htm cross hands praying tattoo
] [http://crea.html.it/websites/yrekzcbtl/prev.htm angel cross tattoo wings
] [http://crea.html.it/websites/wralhl/prev.htm back cross lower tattoo
] [http://crea.html.it/websites/vxrpn/prev.htm christian cross design tattoo
] [http://crea.html.it/websites/spbscf/prev.htm cross greek letter tattoo
] [http://crea.html.it/websites/qykdb/prev.htm cross side stomach tattoo
] [http://crea.html.it/websites/chwahax/prev.htm cross in memory tattoo
] [http://crea.html.it/websites/ebxeif/prev.htm bones cross skull tattoo
] [http://crea.html.it/websites/oqdahoqa/prev.htm cross eva longoria tattoo
] [http://crea.html.it/websites/eskusmtdi/prev.htm cross justin tattoo timberlake
] [http://crea.html.it/websites/ilrnoclg/prev.htm bone cross skull tattoo
] [http://crea.html.it/websites/falxn/prev.htm back butterfly lower tattoo
] [http://crea.html.it/websites/kjkneao/prev.htm butterfly flower picture tattoo
] [http://crea.html.it/websites/kbamprmo/prev.htm butterfly by harley tattoo
] [http://crea.html.it/websites/bbzfim/prev.htm butterfly design tattoo tribal
] [http://crea.html.it/websites/kttwhlcb/prev.htm butterfly design fairy tattoo
] [http://crea.html.it/websites/ibhpelktc/prev.htm butterfly fairy flower tattoo
] [http://crea.html.it/websites/qxutkba/prev.htm butterfly design flower tattoo
] [http://crea.html.it/websites/eottoie/prev.htm butterfly fairy picture tattoo
] [http://crea.html.it/websites/uetqxhapj/prev.htm butterfly gallery picture tattoo
] [http://crea.html.it/websites/cyshqp/prev.htm butterfly design online tattoo
] [http://crea.html.it/websites/kokhg/prev.htm black butterfly design tattoo
] [http://crea.html.it/websites/ychtbe/prev.htm black butterfly tattoo white
] [http://crea.html.it/websites/fangirxoi/prev.htm butterfly picture tattoo unique
] [http://crea.html.it/websites/qreawpuya/prev.htm butterfly free gallery tattoo
] [http://crea.html.it/websites/cqdnlogad/prev.htm butterfly ink iron tattoo
] [http://crea.html.it/websites/nlrfdsor/prev.htm butterfly ink miami tattoo
] [http://crea.html.it/websites/doewns/prev.htm butterfly design flash tattoo
] [http://crea.html.it/websites/aylbpj/prev.htm butterfly fairy tattoo tribal
] [http://crea.html.it/websites/pbuqdae/prev.htm butterfly design picture tattoo
] [http://crea.html.it/websites/ucmlwa/prev.htm butterfly picture small tattoo
] [http://crea.html.it/websites/hqscoxo/prev.htm butterfly design floral tattoo
] [http://crea.html.it/websites/osemscbl/prev.htm picture of tribal tattoo
] [http://crea.html.it/websites/pfwgx/prev.htm tribal art tattoo picture
] [http://crea.html.it/websites/ymwsqp/prev.htm tribal sun tattoo picture
] [http://crea.html.it/websites/llslfhcn/prev.htm upper back tribal tattoo
] [http://crea.html.it/websites/wkxdbpyou/prev.htm behind neck tattoo tribal
] [http://crea.html.it/websites/ajmreiv/prev.htm tribal armband tattoo picture
] [http://crea.html.it/websites/nvjzqars/prev.htm free tribal tattoo flash
] [http://crea.html.it/websites/ralsd/prev.htm tribal dragon picture tattoo
] [http://crea.html.it/websites/igxeiof/prev.htm half sleeve tribal tattoo
] [http://crea.html.it/websites/rsewfufg/prev.htm sea turtle tribal tattoo
] [http://crea.html.it/websites/pyshxd/prev.htm american native tribal tattoo
] [http://crea.html.it/websites/zcqljofi/prev.htm tribal body art tattoo
] [http://crea.html.it/websites/afutfwhsw/prev.htm free tribal cross tattoo
] [http://crea.html.it/websites/dganvd/prev.htm free tribal tattoo art
] [http://crea.html.it/websites/iqpioqvgq/prev.htm tribal sun tattoo pic
] [http://crea.html.it/websites/jftajmbx/prev.htm tribal arm tattoo picture
] [http://crea.html.it/websites/iynzp/prev.htm tribal cross tattoo pic
] [http://crea.html.it/websites/fuvyj/prev.htm band pacific tattoo tribal
] [http://crea.html.it/websites/ryukqx/prev.htm heart tribal tattoo picture] </div>We are beginning the transition from using Seamonkey as our primary Gecko testbed to using Firefox and Thunderbird. Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only preview (calling it "alpha" for now). This preview for Firefox and Thunderbird will fill the release slot that was formerly occupied in the roadmap by "Mozilla 1.8 Beta 2".We were scheduled to freeze for 1.8 Beta 2 on March 15th at midnight but we're not ready for that yet. There is more work, front-end and back-end (cleaning up regressions from new features, completing the heavy lifting of the Thunderbird localization re-organization, fixing key bugs, analyzing and fixing topcrashers, getting XULRunner further along, etc.) that needs to happen before we're in a position to ship the Firefox and Thunderbird 1.1 alphas. We estimate that we can get into shape for the alpha releases in the next 3 to 5 weeks so we're planning on extending the open Mozilla 1.8 Beta 2 development period for at least 3 more weeks.As we get closer to that point, we'll announce the actual freeze date for 1.8 beta 2/Firefox&Thunderbird 1.1 alpha. All changes landed after the freeze date will require drivers' approval and will be limited to the kind of changes necessary to get the 1.1 testing previews shipped. After we ship the 1.1 alphas, we still have work to be done before we're at feature complete (calling that "beta" for now) for the apps, and standing up the XULRunner embedding story. The question arises whether we should branch and do all of this heavy lifting on the branch, to get out of the way of Gecko 1.9 work, or try to stay on the trunk for another cycle and do the work there. If we branch early, we're splitting resources, both developer and QA and we're splitting focus. This was a most unpleasant experience on the 1.7 branch for both the branch and trunk folks. There is probably no way to get around a month or two on the branch, but three months or more sounds like pain.If we decide to branch later, then the tree would stay closed after the alphas and until we ship Firefox and Thunderbird 1.1 beta (and possibly a preview of XULRunner) and digest that feedback. During that tree closure, we'd be focused on responding to the feedback from the 1.1 alphas and fixing both core Gecko and XULRunner issues as well as Firefox and Thunderbird app issues. Being frozen on the trunk after beta, which is also the freeze for localizable strings, would give our L10N teams a chance to get their locales completed or nearly completed on the trunk before branching. This could save them considerable time as compared to branching sooner.Staying closed on the trunk makes little sense if we can't all rally around the tasks that need doing for the 1.8 branch and releases (Firefox, Thunderbird, and XULRunner). We realize that we've got a lot of big work ahead for the 1.9 cycle and not everyone working on Mozilla is working on code directly related to the 1.8 releases so in order to answer the question of when to branch, it would be a great help if you all could note here the work you're doing and your preference for early or later branching. If most are ready to jump on 1.9 work, then we'll branch sooner. If most want to work to make 1.8 releases as solid as possible, then we'll branch later.Here are two possible roadmap diagrams. The first shows a quick branch with overlapping trunk and branch releases and the second diagram shows a longer trunk freeze with a shorter stable branch before 1.8 final products.Thanks to Boris for adding the nifty table under the images. {| border="1"| Branching Early http://piercedotzler.com/asa/rm-2005-03-14.png |-| Branching Late http://piercedotzler.com/asa/rm-2005-03-14-alternate.png |}{| border="1"!Name!Plans|-|Asa|Driving the 1.1 releases and helping out how ever I can with XULRunner.|-|Boris Zbarsky|Currently I'm pretty busy with reviews and cleaning up remaining regressions from the 1.8a cycles. The only 1.9-type thing I'm really working on currently is [https://bugzilla.mozilla.org/show_bug.cgi?id=286000 bug 286000], but I also have some reasonably short-term plans to make the hacks that were landed for aviary for "force open in tab" general enough that embedders can implement equivalent functionality. Other than that, I keep meaning to spend some time on the reflow branch. Given all that, and the amount of work I'll probably end up doing on interface-freezing and the like before 1.8, I think I'm happier with not branching while we have heavy back-end lifting pending and instead perhaps focusing a tad more on the bugs that are blocking the 1.8 betas (and on sorting out which bugs those are).|-|Daniel Brooks|I say branch later.|-|Bernd|I am focused on stability work in table code. Given the long time without a real freeze I would prefer the late branch taking the trunk as a hostage to get the beast stable. This would help both trunk and branch folks on a long run. Or reverse formulated branching from a unstable trunk creates unecessary work on porting.|-|Robert Kaiser|From the L10n point of view, I think that [https://bugzilla.mozilla.org/show_bug.cgi?id=286108 bug 286108] (Thunderbird source L10n) should be completed before branching, so that we don't have to backport those CVS moves to trunk again. From my view in SeaMonkey project, forcing people to work with the "stable" code a bit longer (by branching late) and not opening trunk too soon sounds like a good idea as well, as we need to bundle our resources to get a release out.|-|Wan-Teh Chang|Please update http://www.mozilla.org/roadmap.html#milestone-schedule to reflect the three more weeks of Mozilla 1.8 Beta 2 development period you are considering.|-|Axel Hecht|I have quite a bit of design work to do in the area of RDF, I'm not sure if I can resurrect some of that in the 1.8 cycle. I personally don't have a lot of issues moving that development on a branch myself, so that we have something to land in alpha. Smells like I'm fine with both plans, though the late freeze is going to be smoother AFA l10n is concerned. We could use some of that, I bet, I see stormy parts in that water anyway. Technically ones only, but still.|-|Zbigniew Braniecki|Toolkit source l10n should be ready in 5 weeks. There is amount of work that need to be done by localizers to prepare current CVS localization to be used by Thunderbird. I'd love to see Thunderbird 1.1 beta l10n.|}
| | We are beginning the transition from using Seamonkey as our primary Gecko testbed to using Firefox and Thunderbird. Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only preview (calling it "alpha" for now). This preview for Firefox and Thunderbird will fill the release slot that was formerly occupied in the roadmap by "Mozilla 1.8 Beta 2". |
| | |
| | We were scheduled to freeze for 1.8 Beta 2 on March 15th at midnight but we're not ready for that yet. There is more work, front-end and back-end (cleaning up regressions from new features, completing the heavy lifting of the Thunderbird localization re-organization, fixing key bugs, analyzing and fixing topcrashers, getting XULRunner further along, etc.) that needs to happen before we're in a position to ship the Firefox and Thunderbird 1.1 alphas. We estimate that we can get into shape for the alpha releases in the next 3 to 5 weeks so we're planning on extending the open Mozilla 1.8 Beta 2 development period for at least 3 more weeks. |
| | |
| | As we get closer to that point, we'll announce the actual freeze date for 1.8 beta 2/Firefox&Thunderbird 1.1 alpha. All changes landed after the freeze date will require drivers' approval and will be limited to the kind of changes necessary to get the 1.1 testing previews shipped. |
| | |
| | After we ship the 1.1 alphas, we still have work to be done before we're at feature complete (calling that "beta" for now) for the apps, and standing up the XULRunner embedding story. The question arises whether we should branch and do all of this heavy lifting on the branch, to get out of the way of Gecko 1.9 work, or try to stay on the trunk for another cycle and do the work there. |
| | |
| | If we branch early, we're splitting resources, both developer and QA and we're splitting focus. This was a most unpleasant experience on the 1.7 branch for both the branch and trunk folks. There is probably no way to get around a month or two on the branch, but three months or more sounds like pain. |
| | |
| | If we decide to branch later, then the tree would stay closed after the alphas and until we ship Firefox and Thunderbird 1.1 beta (and possibly a preview of XULRunner) and digest that feedback. During that tree closure, we'd be focused on responding to the feedback from the 1.1 alphas and fixing both core Gecko and XULRunner issues as well as Firefox and Thunderbird app issues. Being frozen on the trunk after beta, which is also the freeze for localizable strings, would give our L10N teams a chance to get their locales completed or nearly completed on the trunk before branching. This could save them considerable time as compared to branching sooner. |
| | |
| | Staying closed on the trunk makes little sense if we can't all rally around the tasks that need doing for the 1.8 branch and releases (Firefox, Thunderbird, and XULRunner). |
| | |
| | We realize that we've got a lot of big work ahead for the 1.9 cycle and not everyone working on Mozilla is working on code directly related to the 1.8 releases so in order to answer the question of when to branch, it would be a great help if you all could note here the work you're doing and your preference for early or later branching. If most are ready to jump on 1.9 work, then we'll branch sooner. If most want to work to make 1.8 releases as solid as possible, then we'll branch later. |
| | |
| | Here are two possible roadmap diagrams. The first shows a quick branch with overlapping trunk and branch releases and the second diagram shows a longer trunk freeze with a shorter stable branch before 1.8 final products. |
| | |
| | Thanks to Boris for adding the nifty table under the images. |
| | |
| | {| border="1" |
| | | Branching Early http://piercedotzler.com/asa/rm-2005-03-14.png |
| | |- |
| | | Branching Late http://piercedotzler.com/asa/rm-2005-03-14-alternate.png |
| | |} |
| | |
| | {| border="1" |
| | !Name |
| | !Plans |
| | |- |
| | |Asa |
| | |Driving the 1.1 releases and helping out how ever I can with XULRunner. |
| | |- |
| | |Boris Zbarsky |
| | |Currently I'm pretty busy with reviews and cleaning up remaining regressions from the 1.8a cycles. The only 1.9-type thing I'm really working on currently is [https://bugzilla.mozilla.org/show_bug.cgi?id=286000 bug 286000], but I also have some reasonably short-term plans to make the hacks that were landed for aviary for "force open in tab" general enough that embedders can implement equivalent functionality. Other than that, I keep meaning to spend some time on the reflow branch. Given all that, and the amount of work I'll probably end up doing on interface-freezing and the like before 1.8, I think I'm happier with not branching while we have heavy back-end lifting pending and instead perhaps focusing a tad more on the bugs that are blocking the 1.8 betas (and on sorting out which bugs those are). |
| | |- |
| | |Daniel Brooks |
| | |I say branch later. |
| | |- |
| | |Bernd |
| | |I am focused on stability work in table code. Given the long time without a real freeze I would prefer the late branch taking the trunk as a hostage to get the beast stable. This would help both trunk and branch folks on a long run. Or reverse formulated branching from a unstable trunk creates unecessary work on porting. |
| | |- |
| | |Robert Kaiser |
| | |From the L10n point of view, I think that [https://bugzilla.mozilla.org/show_bug.cgi?id=286108 bug 286108] (Thunderbird source L10n) should be completed before branching, so that we don't have to backport those CVS moves to trunk again. From my view in SeaMonkey project, forcing people to work with the "stable" code a bit longer (by branching late) and not opening trunk too soon sounds like a good idea as well, as we need to bundle our resources to get a release out. |
| | |- |
| | |Wan-Teh Chang |
| | |Please update http://www.mozilla.org/roadmap.html#milestone-schedule to reflect the three more weeks of Mozilla 1.8 Beta 2 development period you are considering. |
| | |- |
| | |Axel Hecht |
| | |I have quite a bit of design work to do in the area of RDF, I'm not sure if I can resurrect some of that in the 1.8 cycle. I personally don't have a lot of issues moving that development on a branch myself, so that we have something to land in alpha. Smells like I'm fine with both plans, though the late freeze is going to be smoother AFA l10n is concerned. We could use some of that, I bet, I see stormy parts in that water anyway. Technically ones only, but still. |
| | |- |
| | |Zbigniew Braniecki |
| | |Toolkit source l10n should be ready in 5 weeks. There is amount of work that need to be done by localizers to prepare current CVS localization to be used by Thunderbird. I'd love to see Thunderbird 1.1 beta l10n. |
| | |} |
We are beginning the transition from using Seamonkey as our primary Gecko testbed to using Firefox and Thunderbird. Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only preview (calling it "alpha" for now). This preview for Firefox and Thunderbird will fill the release slot that was formerly occupied in the roadmap by "Mozilla 1.8 Beta 2".
We were scheduled to freeze for 1.8 Beta 2 on March 15th at midnight but we're not ready for that yet. There is more work, front-end and back-end (cleaning up regressions from new features, completing the heavy lifting of the Thunderbird localization re-organization, fixing key bugs, analyzing and fixing topcrashers, getting XULRunner further along, etc.) that needs to happen before we're in a position to ship the Firefox and Thunderbird 1.1 alphas. We estimate that we can get into shape for the alpha releases in the next 3 to 5 weeks so we're planning on extending the open Mozilla 1.8 Beta 2 development period for at least 3 more weeks.
As we get closer to that point, we'll announce the actual freeze date for 1.8 beta 2/Firefox&Thunderbird 1.1 alpha. All changes landed after the freeze date will require drivers' approval and will be limited to the kind of changes necessary to get the 1.1 testing previews shipped.
After we ship the 1.1 alphas, we still have work to be done before we're at feature complete (calling that "beta" for now) for the apps, and standing up the XULRunner embedding story. The question arises whether we should branch and do all of this heavy lifting on the branch, to get out of the way of Gecko 1.9 work, or try to stay on the trunk for another cycle and do the work there.
If we branch early, we're splitting resources, both developer and QA and we're splitting focus. This was a most unpleasant experience on the 1.7 branch for both the branch and trunk folks. There is probably no way to get around a month or two on the branch, but three months or more sounds like pain.
If we decide to branch later, then the tree would stay closed after the alphas and until we ship Firefox and Thunderbird 1.1 beta (and possibly a preview of XULRunner) and digest that feedback. During that tree closure, we'd be focused on responding to the feedback from the 1.1 alphas and fixing both core Gecko and XULRunner issues as well as Firefox and Thunderbird app issues. Being frozen on the trunk after beta, which is also the freeze for localizable strings, would give our L10N teams a chance to get their locales completed or nearly completed on the trunk before branching. This could save them considerable time as compared to branching sooner.
Staying closed on the trunk makes little sense if we can't all rally around the tasks that need doing for the 1.8 branch and releases (Firefox, Thunderbird, and XULRunner).
We realize that we've got a lot of big work ahead for the 1.9 cycle and not everyone working on Mozilla is working on code directly related to the 1.8 releases so in order to answer the question of when to branch, it would be a great help if you all could note here the work you're doing and your preference for early or later branching. If most are ready to jump on 1.9 work, then we'll branch sooner. If most want to work to make 1.8 releases as solid as possible, then we'll branch later.
Here are two possible roadmap diagrams. The first shows a quick branch with overlapping trunk and branch releases and the second diagram shows a longer trunk freeze with a shorter stable branch before 1.8 final products.
Thanks to Boris for adding the nifty table under the images.
Branching Early 
|
Branching Late 
|
| Name
|
Plans
|
| Asa
|
Driving the 1.1 releases and helping out how ever I can with XULRunner.
|
| Boris Zbarsky
|
Currently I'm pretty busy with reviews and cleaning up remaining regressions from the 1.8a cycles. The only 1.9-type thing I'm really working on currently is bug 286000, but I also have some reasonably short-term plans to make the hacks that were landed for aviary for "force open in tab" general enough that embedders can implement equivalent functionality. Other than that, I keep meaning to spend some time on the reflow branch. Given all that, and the amount of work I'll probably end up doing on interface-freezing and the like before 1.8, I think I'm happier with not branching while we have heavy back-end lifting pending and instead perhaps focusing a tad more on the bugs that are blocking the 1.8 betas (and on sorting out which bugs those are).
|
| Daniel Brooks
|
I say branch later.
|
| Bernd
|
I am focused on stability work in table code. Given the long time without a real freeze I would prefer the late branch taking the trunk as a hostage to get the beast stable. This would help both trunk and branch folks on a long run. Or reverse formulated branching from a unstable trunk creates unecessary work on porting.
|
| Robert Kaiser
|
From the L10n point of view, I think that bug 286108 (Thunderbird source L10n) should be completed before branching, so that we don't have to backport those CVS moves to trunk again. From my view in SeaMonkey project, forcing people to work with the "stable" code a bit longer (by branching late) and not opening trunk too soon sounds like a good idea as well, as we need to bundle our resources to get a release out.
|
| Wan-Teh Chang
|
Please update http://www.mozilla.org/roadmap.html#milestone-schedule to reflect the three more weeks of Mozilla 1.8 Beta 2 development period you are considering.
|
| Axel Hecht
|
I have quite a bit of design work to do in the area of RDF, I'm not sure if I can resurrect some of that in the 1.8 cycle. I personally don't have a lot of issues moving that development on a branch myself, so that we have something to land in alpha. Smells like I'm fine with both plans, though the late freeze is going to be smoother AFA l10n is concerned. We could use some of that, I bet, I see stormy parts in that water anyway. Technically ones only, but still.
|
| Zbigniew Braniecki
|
Toolkit source l10n should be ready in 5 weeks. There is amount of work that need to be done by localizers to prepare current CVS localization to be used by Thunderbird. I'd love to see Thunderbird 1.1 beta l10n.
|