90 likes | 221 Views
STF 393. MTS#50 Decisions. CR priorities high : bug fixes (editorials go “automatically to editors”, clarifications normal : minor additions low : major additions CRs are processed according to class priorities within the class according to submission date (FIFO)
E N D
MTS#50 Decisions • CR priorities • high: bug fixes (editorials go “automatically to editors”, clarifications • normal: minor additions • low: major additions • CRs are processed according to class priorities • within the class according to submission date (FIFO) • MTS can “fast track” specific CRs: use urgent prio for this • How to avoid too much delay of low prio CRs due to too many high and normal prio ones? -> considered to be a non-issue at the moment, to be re-discussed if the situation occurs • exceptions for CRs felt to be of high prio? • weighting: 5 prio1, 2 prio2, 1 prio1 ?
CR Status • new • the status when a CR is submitted or at the beginning of a new STF • clarification of the content (STF) • assigned • preparing an analysis and (alternative) solution(s) (CR responsible) • analysis and alternatives discussed (STF)-> principal solution can be taken by the STF-> vendors shall be involved (not-backward compatibility) to agree the principal solution (managed by CR responsible); • proposed text to be prepared by CR responsible • review of proposed text (iteratively) (reviewer, CR resp.) • feedback • the CR is waiting an additional input from the provider or tool vendors • vendors list to be updated! • resolved • final agreed text of changes in the standard(s) exists (CR resp.) • CR resp. assigns the CR to the rapporteur • closed • standard rapporteur implements text in the draft • PLS. always include the no.s of implemented CRs into the HISTORY of the draft • Set the Fixed in Version and Resolution fields in Mantis (if not et done)
CR Resolution • open • default when the CR is entering • fixed • Action is taken on the CR (error correction, clarification is added, new feature added, solution not necessarily as proposed in the CR) • won’t fix • The problem described by the CR is outdated or based on a misunderstanding, no further action is taken on the CR • reopened • The submitter is not satisfied with the STF solution in a resolved/closed and wants to re-open the CR • duplicate • the CR (or its resolution) is handled together with another CR due to technical similarities
CR process (cont.d) • CR admittance closed • At the beginning of the last session (or earlier?) • For the last session only bugfix CRs are admitted (as new ones) • Last session is mainly to “clean up” CRs already being processed (final agreements and drafting of text) • Open questions: • If a CR effects more than 1 parts • the CR will be cloned per person (rapporteur or assigned CR responsible) to allow working in parallel and make resolution and implementation track-able
CR process (cont.d) • Rapporteur • Shall follow the progress of CRs related to his/her document • Rapporteurs (equals to editors, unless decided differently): • Part-1: Ina • Part-4: Jens • Part-5: Ina • Part-6: Ina • Part-7: Gyorgy • Part-8: Gyorgy • Part-9: Gyorgy • Part-10:Gyorgy • Ext. Behaviour types: Jens • Ext. Adv. param.: Jens • Ext. Depl. & config.: Jens • Ext. Perf.& real time: Jens • Ref. TS framework: Benjamin
STF transparency • STF session plan to be sent on MTS_GEN • CR classification to be sent on MTS mailing list at the beginning of each session • CR resolution summary to be sent on MTS_GEN at the end of each session • After the 2nd STF session • CR resolution summary (cumulative) to be sent over the MTS_GEN list • CR summary meeting (by phone/on line meeting), invitation to be sent over MTS_GEN • Next editions • Interim versions mid 2010; non-official, to be uploaded to MTS drafts area; no extra work should be put on this but CR resolution should be scheduled to make this possible (Part-6: .NET mapping preferably should be incl.); • ES 201 873-1, -4, -5, -6, -7, -8, -9, -10 v4.3.1,to be delivered by end of December 2010, internally should be mid Dec. • Extension packages and Ref. TS: next subsequent version no.to be delivered by end of December 2010, internally should be mid Dec. • Ref. TS: STF 393’s responsibility is to maintain the framework only, no test cases to be added (MTS requests for a separate STF from the 2nd allocation)
Urgent issues for w12 • Part-1, Part-4 • CRs reporting errors: CR5490, CR5486, CR5343 • 3GPP issues: CR5174 • Part-5, -6 • CR5485+CR5489 • CR5174 • CR5394/CR5395 .NET mapping: check if possible in v4.2.1 or in the interim (see prev. slide) • Part-7 • CR5212, CR5342 • Part-9 • CR5465 • Ref. TS: • create one ETS document from the 3 already delivered • Discuss and give a rough estimate of testable requirements in the core • in terms of number • in terms of required mMonth (for a req. catalogue) • Editorial CRs acc. to classification • v4.2.1 parts shall be final-finalized by this Friday; Gyorgy sends a list of updated parts to Laurent on Friday • STF presentation in Beijing, T3UC • Decide presenter • Content of the presentation (at least at the skeleton level)
AOB • None