Gnome 2.2

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]

After 2.0.2⁰: Begin work on 2.1.x.

hackers focus on: cool stuff :), listing that cool stuff so that everyone else knows what is going on

UI/a11y focus on: finishing documentation for all hackers to use¹

Oct. 31st: feature freeze, UI chill², completion of UI/a11y docs

hackers focus: feature completion, bug fixing

UI/a11y teams: identify bugs in UI- all UI changes should be approved by UI/a11y teams after 'chill’ starts

marketing and QA: get a hard feature list, inc. new modules³

Nov. 30th: UI freeze except for fixing of bugs filed by UI/a11y teams

hackers focus: fix bugs

QA: identify features that are incomplete and must wait for 2.4, and notify marketing of the things that are getting dropped

UI/a11y: assist hackers in fixing bugs identified before freeze⁴

Four weeks before RC [12/28]: hard i18n string freeze

after this point, fixes (including UI/a11y) go in only if they have no string impact and low stability risk.

Note that this is specified as 'four weeks before RC’ on the supposition that if the RC is moved for quality reasons string freeze should also be moved.

Jan. 31st: 2.2.0 release

hackers, release team, others: drink heavily

QA team: read bugs, drink more heavily

rinse, repeat for 2.4
RELEASES (very tentative, based roughly on the current three-week cycle):

2.0.2: Week ending Sept. 6th

2.1.0: ” Sept. 27th

2.1.1: ” Oct. 18th: 'October GNOME, take two’

2.1.2: ” Nov. 1st: the 'UI and a11y teams, do your worst’ release [Note only a two week cycle here]

2.1.3: ” Nov. 22nd: the 'last chance to report UI/a11y bugs’ release

2.1.4: ” Dec. 13th: the 'last chance to report string bugs’ release

2.1.5: ” Jan. 3rd: the 'release that will never happen because no one will want to roll tarballs this close to new years’ release⁵

2.1.90 (RC1): ” Jan. 24th: the 'these tarballs should be final’ release⁶

2.2.0: Jan. 31st: the 'release’ release
FOOTNOTES:
⁰ 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 🙂
¹ 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.
² 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.
³ Anything on this list not of sufficient quality by Nov. 31st will be dropped at that time. ⁴ 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.]
⁵ Eck. Totally hadn’t considered the need for RCs when thinking about January 31st as a release date. Any thoughts on that?
⁶ 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?
Other notes:

This is a schedule centered around 30/31 day cycles, not 3 week cycles as per our last one. This introduces some issues- like a release on January 3rd. :/

The marketing team feels strongly that we should aim for mid-January so that we can announce at LinuxWorld New York, which would be pretty cool. Much of the rest of release team is worried about hackers and their availability and willingness to hack during January. It’s a noble goal– if we believe we can hit it. Thoughts/comments?

This doesn’t touch the issue of API freezes for core libraries; /if/ we think this is going to actually be an issue then we really need to address it.

Release numbering- what do maintainers think about numbering their releases based on the gnome release? i.e., 2.1.1.0 for the release that goes out with GNOME 2.1.1, 2.1.1.1 for the first snap release after 2.1.1, etc.? This is really sort of micro-managerial so we’re reluctant to ask this, but it would help packagers and general organization.

We need to think about criteria for the 2.0.x series and its releases in a separate discussion, IMHO, but it definitely needs to be talked bout — who is going to do it, when it will be done, how we decide when it will be done, etc.
Tiredly and on behalf of the release team
Luis

Archiwalny news dodany przez użytkownika: pbs.
Kliknij tutaj by zobaczyć archiwalne komentarze.