The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht am 21.01.2010 und auf Englisch an. Zurück zu allen aktuellen Beiträgen | |||||||||||||||||||||||||||||||||||||||||||
21. Jänner 2010
Automated Updates for Localized SeaMonkey Trunk Nightlies
I've been working on this for a few days now - and with some teak of last night it finally started working:
Localized nightlies for SeaMonkey "trunk" (i.e. those from latest-comm-central-trunk-l10n) now get automated updates, just like the US English ones do!
Of course, you'll only get an update if one is available, but string changes in Mozilla or SeaMonkey areas should not pose problems, our build system "merges" localizations for nightlies with the US English strings, so that you just will see untranslated strings where the localizer still has work to do.
In case ChatZilla or venkman have missing strings, we will break in the build stage and not produce nightlies or updates, though, as the "l10n-merge" process is currently unable to deal with those extensions.
I hope nightly testers will be happy and our localizations will get even more testing even before we ship alphas, betas or releases!
Localized nightlies for SeaMonkey "trunk" (i.e. those from latest-comm-central-trunk-l10n) now get automated updates, just like the US English ones do!
Of course, you'll only get an update if one is available, but string changes in Mozilla or SeaMonkey areas should not pose problems, our build system "merges" localizations for nightlies with the US English strings, so that you just will see untranslated strings where the localizer still has work to do.
In case ChatZilla or venkman have missing strings, we will break in the build stage and not produce nightlies or updates, though, as the "l10n-merge" process is currently unable to deal with those extensions.
I hope nightly testers will be happy and our localizations will get even more testing even before we ship alphas, betas or releases!
Von KaiRo, um 16:03 | Tags: L10n, Mozilla, SeaMonkey | 1 Kommentar | TrackBack: 2
SeaMonkey 2.1 planning
Now that our last stable release has been shipped, the first updates have been done to make it even more solid, and the holidays have passed, it's time to start concentrating on our next feature release a bit more.
This includes trying to come up with some kind of plans, as we've seen in the quite long SeaMonkey 2.0 development period that we only get good at progress when we have good plans for what we want to do and even when we want to have it done.
So, there are a number of things we know about this upcoming release already:
From how I know our work flow, and where we stand right now, i.e. completely at the beginning of 2.1 work, I estimate the earliest possible time we could stabilize for a release would be in June or July of this year - on the other hand, we should not take longer than a year after 2.0 to release, as we really need to show that we are more active that ever and that SeaMonkey is not a dying product but going quite strong. It's better to release more often in smaller steps and put off some work to the next release than to make the impression that nothing is going on and lose people to Firefox, Thunderbird, or Opera.
Some point of insecurity in our planning is that the Mozilla platform doesn't have any clear roadmap for 2010 or even the next months as of now. Originally, there was a plan to release 1.9.3 in summer, but Firefox developers feel that too frequent updates can be painful for add-on users and authors and wonder if and which features from development they can backport to the stable 1.9.2 series instead. A summer platform release would probably fit our release plans very well, but from where we are now, we can't count on that.
Because of that, we need to see that we have our code compatible with 1.9.2 and 1.9.3 at the same time, so we can jump either way depending on where the platform plans manifest themselves. I guess we can keep that up for a few weeks, but as soon as we come to an alpha, we at least need to pronounce one tree to be official. Given our lack of build machines, we can only run tests on 1.9.1 right now and only do nightlies for one tree next to 1.9.1, but I hope that will change (I did set up some experimental build trees for 1.9.2 now, at least, but they only do "hourly" builds, which take up less time on the machines).
In any case, now is the right time to really start attacking all the things we want to have implemented in a SeaMonkey 2.1 release, and help from everyone is highly recommended!
Also, please make sure all regressions from 2.0 to current trunk nightlies are filed in Bugzilla, marked as regressions, and possibly at least nominated for blocking-seamonkey2.1a1 so that we can make sure we know where we are for eventually shipping that beast.
We will want to have at least one alpha and one beta, which 6-8 weeks spacing between those and from the last beta to release, so you can easily see how we need to come near to having real plans in our minds.
What opinions does the community have on that? What can you do to help us reach a good and possibly even better release than the last one?
Remember, this community does not work by telling others what to do (not even I or the SeaMonkey Council can do that), but by standing up, taking matters into your own hands and working together for a really valuable community-driven SeaMonkey product.
So what can you do, can you work with what I writing about here? How can plans be made to accommodate your work better?
This includes trying to come up with some kind of plans, as we've seen in the quite long SeaMonkey 2.0 development period that we only get good at progress when we have good plans for what we want to do and even when we want to have it done.
So, there are a number of things we know about this upcoming release already:
- We probably want to name it "SeaMonkey 2.1".
- It should incrementally improve on 2.0, incorporate a few things we let slip for that previous release, and be a much smaller and faster step than 2.0.
- We have a good number of wanted features/improvements (with even more nominated), among them being mailnews API refactorings, OpenSearch, form data editor, places bookmarks, and more theme icon work.
- We want to use a newer Gecko/platform version than 1.9.1 and ideally connect up to being at the edge of Gecko releases once again.
- Platform changes in newer versions might influence SeaMonkey features (e.g. any post-1.9.1 version loses import of download history - a minor inconvenience, but a nice example).
- We would really like to pick up startup improvements of newer platform releases, esp. 1.9.3, and the out-of-process-plugins (OOPP) feature as soon as possible once it's stable (Flash crashing won't take down both browser and mailnews any more, it will just make the plugin stop working in that one tab).
- We need more build infrastructure to support this release as an additional build/release tree (bugs are filed, but the process to actually get things done always takes a while).
From how I know our work flow, and where we stand right now, i.e. completely at the beginning of 2.1 work, I estimate the earliest possible time we could stabilize for a release would be in June or July of this year - on the other hand, we should not take longer than a year after 2.0 to release, as we really need to show that we are more active that ever and that SeaMonkey is not a dying product but going quite strong. It's better to release more often in smaller steps and put off some work to the next release than to make the impression that nothing is going on and lose people to Firefox, Thunderbird, or Opera.
Some point of insecurity in our planning is that the Mozilla platform doesn't have any clear roadmap for 2010 or even the next months as of now. Originally, there was a plan to release 1.9.3 in summer, but Firefox developers feel that too frequent updates can be painful for add-on users and authors and wonder if and which features from development they can backport to the stable 1.9.2 series instead. A summer platform release would probably fit our release plans very well, but from where we are now, we can't count on that.
Because of that, we need to see that we have our code compatible with 1.9.2 and 1.9.3 at the same time, so we can jump either way depending on where the platform plans manifest themselves. I guess we can keep that up for a few weeks, but as soon as we come to an alpha, we at least need to pronounce one tree to be official. Given our lack of build machines, we can only run tests on 1.9.1 right now and only do nightlies for one tree next to 1.9.1, but I hope that will change (I did set up some experimental build trees for 1.9.2 now, at least, but they only do "hourly" builds, which take up less time on the machines).
In any case, now is the right time to really start attacking all the things we want to have implemented in a SeaMonkey 2.1 release, and help from everyone is highly recommended!
Also, please make sure all regressions from 2.0 to current trunk nightlies are filed in Bugzilla, marked as regressions, and possibly at least nominated for blocking-seamonkey2.1a1 so that we can make sure we know where we are for eventually shipping that beast.
We will want to have at least one alpha and one beta, which 6-8 weeks spacing between those and from the last beta to release, so you can easily see how we need to come near to having real plans in our minds.
What opinions does the community have on that? What can you do to help us reach a good and possibly even better release than the last one?
Remember, this community does not work by telling others what to do (not even I or the SeaMonkey Council can do that), but by standing up, taking matters into your own hands and working together for a really valuable community-driven SeaMonkey product.
So what can you do, can you work with what I writing about here? How can plans be made to accommodate your work better?
Von KaiRo, um 14:46 | Tags: Mozilla, SeaMonkey, SeaMonkey 2.1 | 12 Kommentare | TrackBack: 1
