Differences between revisions 1 and 2
Revision 1 as of 2007-03-14 19:59:07
Size: 4416
Comment: First version, not yet polished
Revision 2 as of 2007-03-14 19:59:58
Size: 4383
Comment: No link there
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Details of the [wiki:Self:I18n/DebconfReview debconf review] process = = Details of the debconf review process =
Line 139: Line 139:

Details of the debconf review process

Step 1: notify the package maintainer

<DAY00> to <DAY06>

One of the members of the rewrite team ("the reviewer") notifies the package maintainer and other rewrite team members of the intent to work on the package's templates.

This is intended to avoid collisions with rewrite or any other work that could have been planned by the maintainer.

The reviewer sends a message with "[ITR] templates://<package>/{file1,...,fileN}" (ITR=Intent To Review) to both the maintainer and the debian-l10n-english mailing list.

A 7 days delay is given to the package maintainer to ACK for this action or deny it.

The reviewer grabs the package's source tree and subscribes him/herself to the PTS for that package.

The package maintainer is <package>@packages.debian.org

Text used: intent.txt

Step 2: Call for debconf templates review


The reviewer sends the package's templates file to debian-l10n-english for review with "[RFR] templates://<package>/{file1,...,fileN}" as Subject.

Text used: rfr.txt

Step 3: Review

<DAY07> to <DAY16>

The debian-l10n-english contributors review the templates file and propose changes by sending unified diffs in debian-l10n-english as followups to the RFR message.

After "enough" time, the reviewer summarizes the changes with a "Last Call for Comments" mail 1 or 2 days before the end of the review process. In case it becomes obvious that everything is correct, this delay can be shortened. The mail subject should be "[LCFC] templates://<package>/{file1,...,fileN}"

This mail will we CC'ed to the package maintainer to give her/him a chance to react to the proposed changes.

Text used: lcfc.txt

Step 4: Send the review to the BTS


The reviewer sends this rewritten templates file as a bug report against <package> with: Severity: wishlist Tags: patch Subject: <package> Debconf templates rewrite/proofreading

This bug's number will be <bugnumber> in the following.

This bug will be usertagged "rewrite" by the debian-i18n@lists.debian.org user.

The reviewer sends a mail to debian-l10n-english with "[BTS] templates://<package>/{file1,...,fileN} #<bugnumber>" as Subject.

Texts used: bug-report.txt and bts.txt

Step 5: Call for translation updates


The reviewer includes the new templates file(s) to his/her copy of the package sources, runs debconf-updatepo and sends calls for updates:

podebconf-report-po --languageteam --deadline="<DAY28>" --bts=<bugnumber>

podebconf-report-po --call --deadline="<DAY28>" --bts=<bugnumber>

Text used: call-updates.txt and call-new.txt

Step 6: Translation updates

<DAY16> to <DAY28>

Translation teams work on the translation updates of new translations by using their respective translation processes.

Updates are sent to <bugnumber>@bugs.debian.org with: Subject: <package>: [INTL:xx] Debconf translation update

(replace "Debconf translation update" by "New debconf translation" for new translations)

The reviewer integrates these updates to his/her copy after checking the encoding and "msgfmt -o /dev/null -c <pofile>"

Step 7: Send the patch to the package maintainer


The reviewer builds a patch against the previous version of <package> by buildign a tarball with: - debian/changelog - debian/*templates (the real names depends on the real templates file) - debian/po/*.po

This patch is sent to <bugnumber>@bugs.debian.org.

The package maintainer is given a 7 days delay to react and either: - upload a fixed package - notify the reviewer that (s)he can NMU the package - request for no NMU to happen but give an exmplanation for this

Text to use: patch.txt

Step 8: Waiting for the upload

<DAY30> to <DAY36>

The reviewer follows further actions on the package.

In case a NMU is accepted, the NMU is built and uploaded (either by the reviewer or by a sponsor)

Step 9: NMU the package


(this step only occurs when a NMU is done)

The package is uploaded with fixed templates and translations. The NMU patch is sent to <bugnumber>.

Text to use: nmu-patch.txt

About delays and timing

Of course, all these delays, except the call for translations, can be shortened if the situation allows for this.