Wydane pod koniec czerwca Gnome 2.0 było raczej środowiskiem dla deweloperów, pozwalającym im powoli przenosić swoje aplikacje i tworzyć nowe. Zwykli użytkownicy na razie nie nacieszą się nim za bardzo. Jednak już w tej chwili zaproponowano harmonogram prac nad wydaniem wersji 2.2 tego środowiska. Prace nad tą wersją mają być zakończone pod koniec stycznia 2003. Poniżej zamieszczamy list Luis Villa do deweloperów Gnome, zawierający propozycję tegoż harmonogramu.
So… we’re very nearly at the 2.0.1 release, and a lot of people are itching to start on 2.2. Which maybe means we need a schedule. Here’s the current thinking of the release team. We’d like to finalize this RSN so please send your thoughts and feedback and flames and such ASAP. :) It’s important all the way through, so please read all of it :) ‚Other notes’ in particular deserve thought.
Most Important Dates:
[followed by things which start on that date]
RELEASES (very tentative, based roughly on the current three-week cycle):
0 Or after 2.0.1 for apps that feel they are Ready. Ready is a judgement call, of course… certainly the more bugfixing between 2.0.1 and 2.0.2 the better off we’ll be when we start 2.1, so we strongly encourage most modules to wait until after 2.0.2 :)
1 It is my firm belief that if there are no complete HIG/a11y docs, we’re never going to have decent compliance with either of these, and so those teams would have three months from today to complete those docs so that hackers can use them. Bugs not covered by those documents will not be considered high priority for the 2.2 release. The teams would still have three months after document completion to ID bugs and fix them before 2.2.0.
2 Past this point, UI is in the hands of the usability and a11y teams; hackers should have done from a UI perspective everything they want to do at this point. If hackers want to add more UI at this point, it has to go by the UI and a11y teams.
3 Anything on this list not of sufficient quality by Nov. 31st will be dropped at that time. 4 If the UI and a11y teams have not identified a problem by the 31st, unless it is of the utmost severity, it’s a 2.4 thing. Bugs they’ve identified by this point are still fixable in the 2.4 time frame and can become release blockers. [a11y bugs that don’t impact UI/doc/string freeze can be identified/fixed after this date, of course.]
5 Eck. Totally hadn’t considered the need for RCs when thinking about January 31st as a release date. Any thoughts on that?
6 effectively this gives (with tarballs for a rc theoretically final) only three weeks for i18n. This is probably too short. Suggestions/comments, Kjartan, Menthos, rest of i18n team?
Tiredly and on behalf of the release team
Archiwalny news dodany przez użytkownika: pbs.
Kliknij tutaj by zobaczyć archiwalne komentarze.