[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

My work method for the current l10n non-maintainer uploads campaign



(CC'ed to -qa as this may be seen as some kind of QA work)

Some of you have noticed the "NMU campaign" (NMU==non-maintainer
upload, ie building an uploading a package while you're indeed not the
official maintainer for it) currently running for fixing longstanding
l10n bugs (up to now debconf translations).

This mail is aimed at giving you details about the way I proceed.

These "l10n NMUs" have to be made very carefully as non-maintainer
uploads for fixing bugs which are considered non critical are often
not well received if not made with a lot of care, including great
respect for maintainers work (not all these packages are abandoned
ones!).

The process is the following:

1 build a list of target packages (I use the list of pending French 
  translations....I know that Luk Claes wants to do the same for
  pending Dutch translations. See below

2 for each package:
  2.1 first post a notice to the maintainer only (text number 1)
      mentioning the concern about pending l10n bugs and proposing
      solutions (including a non maintainer upload)
  2.2 if no answer comes, or if the maintainer agrees for a NMU,
      wait for 7 days and post a "NMU intent" mail to both the
      maintainer and the -i18n list. These are those you have seen 
      in the past days. The "NMU intent" calls for updates to
      incomplete or missing translations (text number 2)
  2.3 a few days later (2-3), build the package with the received
      updates and all pending l10n bugs. Also fix trivial bugs the
      package may have (lintian warnings, often) as long as the
      fix is really trivial
  2.4 upload the package to the delayed queue and send the full
      patch of the NMU to the BTS as a contribution to one of the 
      fixed l10n bugs (text number 3)
  2.5 after 2 days, the package gets uploaded to incoming
      and the bugs are closed
  2.6 subscribe to the package's PTS so that I can be aware of
      any bug introduced by the NMU

In any case, if the maintainer answers between 2.1 and 2.2, the
process is interrupted unless (s)he mentions me that a NMU is welcome
(it already happened for lsh-utils). Quite often, the first mail acts
as a reminder and the maintainer takes care of fixing theses pending
bugs on his/her own. It happened for about one third of the packages I
have already pinged up to now.

Packages completed:
 iterm
 lsh-utils
 mrtg

Packages which reached 2.2 (NMU likely to happen):
 oops
 spamprobe

Packages which reached 2.2 but unable to build:
 atlas

Packages with first notice sent, waiting for 7 days delay:
 firebird
 isoqlog
 nap

Packages with first notice sent, maintainer makes the update:
 ckermit
 conserver
 getmail (will be removed from archive)
 gwhois
 keychain
 mediamate
 spip
 teapop

Packages  to do (more than 100days pending French translation)
 apple2
 bindgraph
 blosxom
 diablo
 exult
 ipvsadm 
 libpam-radius-auth
 opendb 



================================================================
Text1: sent to the package maintainer

Dear Debian maintainer,

The <package> Debian package, which you are the maintainer of, has at
least one very longstanding (over 100 days) localisation bug
report. Often, but not always, this means that the package is not very
actively maintained. I'm sending you this mail for checking the
situation and to decide the next necessary steps. If there is some
reason why you haven't fixed the bug yet, or there is something other
you might want to tell me, i will be very happy about any feedback. In
this case please accept my apologies.

I have the intent to build and possibly upload a non-maintainer upload
for <package> in order to fix all its long-time pending
localisation bugs (and these bugs only).

Such changes are always harmless, which explains why I safely consider
building NMU's for such issues even though they're obviously non
critical.

However, letting l10n bugs sleep in the BTS is simply not giving
translators work the consideration it deserves, as fixing debconf
translations is really a very simple modification to any package.

This makes me call such NMU's "socially important" : when translators
(who often are not official Debian developers but participate in in
creasing our distribution diffusion) see that thei work is taken care
of, they are more and more motivated for contuing their sometimes
boring activity..:-)

I will notify the translators for languages for which the
translation is still incomplete without update sent to the BTS so that
they have a chance to send updates on time.

The schedule for the NMU (in case it happens, that is if you agree with
it or if I don't receive any answer in 7 days) is roughly the
following:

-<DAY00>   : send this notice
-<DAY01>   : post a NMU announcement to debian-i18n with you
                (maintainer) CC'ed
-<DAY02>   : deadline for receiving translation updates
-<DAY03>   : build the package and upload it to DELAYED/2-day
                send the NMU patch to the BTS
-<DAY04>   : NMU uploaded to incoming
-<DAY05>   : NMU enters unstable

The patch for the NMU will then be sent to one of the l10n bugs so
that you may incorporate it to your development tree later.

I will then subscribe to the Package Tracking System for <package> and
follow its life for 60 days after my NMU in order to fix any issue
potentially introduced by my upload.

So, dear package maintainer, please mention me as soon as possible if
you have any kind of objection to this process.

If you'd rather do the fix yourself, I will of course leave the
package alone. Same if you have motivated reasons for not doing the
update now.

Please keep debian-i18n@lists.debian.org CC'ed so that all Debian
translators are aware of your intents regarding translation handling.

Of course, any other translator wanting to have <package>
debconf templates translated in his/her language is welcome to quickly
work on the templates.pot.gz file which can be found on
http://www.debian.org/intl/l10n/po-debconf/pot.

You can then send your PO file in the BTS (tagging it "l10n", severity
"wishlist").


================================================================
Text 2: sent to the package maintainer and debian-i18n
        7 days later

Dear maintainer of <package> and Debian translators,

On <DAY00>, I sent a notice to the maintainer of the <package> Debian
package, mentioning the status of pending localization bug reports in
the BTS.

I announced the intent to build and possibly upload a non-maintainer
upload for this package in order to fix all its long-time pending
localisation bugs (and these bugs only).

Since then, I didn't get any objection from the package maintainer and
then I will start the second phase of the process.

If needed, I will notify the translators for languages for which the
translation is still incomplete without update sent to the BTS so that
they have a chance to send updates on time.

The package is currently translated to: <COMPLETE>

The following translations exist but are incomplete: <INCOMPLETE>
            (even after applying pending l10n bugs, of course)

Other translators also have the opportunity of creating a translation
in their language for this package. Please go to
http://www.debian.org/intl/l10n/po-debconf/pot and pick up the
relevant templates.pot.gz file. Once completed, please send it
directly to me so that I incorporate it in the package being built.

The deadline for receiving updates and new translations if fixed to
<DAY02>.

Of course, if in the meantime the maintainer objects to this process,
I will stop it and send him/her all updates I have received.

Otherwise, the following will happen (or already have):
-<DAY00>   : send the first intent to NMU notice to
             the package maintainer
-<DAY01>   : this announcement
-<DAY02>   : deadline for receiving translation updates
-<DAY03>   : build the package and upload it to DELAYED/2-day
                send the NMU patch to the BTS
-<DAY04>   : NMU uploaded to incoming
-<DAY05>   : NMU enters unstable

As you may see, the NMUed package will be built and then uploaded to
DELAYED/2-day, giving the maintainer two more days for reacting to the
NMU.

I will then subscribe to the package PTS and follow its life for 60
days after my NMU in order to fix any issue potentially introduced by
my upload.

Of course the NMU patch will also be sent to the BTS.


===========================================================
Text 3: sent along with the NMU

This text depends on the context and the fixed bugs. I usually post a
changelog so that it is easy to see what has been fixed and/or changed.



-- 






Reply to: