On Tue, 14 Apr 2009 22:42:30 +0200 Cyril Brulebois <kibi@debian.org> wrote: > Neil Williams <codehelp@debian.org> (14/04/2009): > > > > http://dep.debian.net/deps/dep4/#index9h2 > > > > > > You probably need to clarify in your DEP what “initial” means. > > > > This section covers part of that: > > http://dep.debian.net/deps/dep4/#index9h2 > > > > "When the maintainer makes a new release, foo1.2.3-5, which incorporates > > the TDeb changes, it is done in a similar manner to how an NMU is > > included. All files matching foo*1.2.3-4* are removed by dak when the > > new version is uploaded. The updated translations now exist in > > foo-tdeb1.2.3-5all.tdeb - uploaded by the maintainer and there is no > > +t1.diff.gz or +t1all.tdeb until the package translations need to be > > touched again." > > > > I'll extend the section to describe +t0 in terms of each maintainer > > upload, whether that is a new Debian version or a new upstream release > > for non-native packages. > > What I mean is that the title of the whole section is “Initial uploads”. > You probably want to tell in the very first sentence OK, I'll update that. > > > > > It can > > > (AFAICT, I'm no native speaker etc.) be understood as the first time > > > ever translation stuff is set up (once the toolchain is in place), or > > > the first upload without additional translations (that would be +tN > > > uploads, N>0), which, I would *guess* could be either an MU or an NMU. > > > > +t0 is each and every maintainer upload. The maintainer builds the TDeb > > each time, as if it was +t0. > > Or the uploader when it is an NMU? OK. > > > Well. If people send translations through the BTS, or whatever other > > > means, why wouldn't the maintainer be the one merging them in a > > > translation-only upload? > > > > http://dep.debian.net/deps/dep4/#index7h2 > > "During the transition, those bugs will remain. After the transition, > > those bugs will go away so there should be no need for a closure > > method. We’ll need to rely on i18n.debian.org for translation tracking > > after Squeeze." > > I don't really care about the transition, I'm talking about the final > state, with ponies et al. People might still be used to reporting bugs > into the BTS, and one may want to grab the translations from there. I think we can leave that for i18n.debian.net to sort out - there are systems already in place to monitor such things and if maintainers get direct email then maybe it's best to forward that to debian-i18n@l.d.o to avoid duplicate translations. > > There's no reason to discuss the precise methods now, but there does > > not need to be any use of the BTS for translator uploads, the whole > > +t1 can be handled internally in i18n.debian.net. > > Well, clarifying what benefits in the end are seems worth to mention, to > understand how tdebs are (or not) a good thing™. As long as the minutiae are not set in stone before the implementation has had a chance to settle in. > > > That would mean spared buildd cycles, > > > > There are no buildd cycles involved - TDebs are Arch:all. > > Bleh. Say I want to include a German translation in Blender. I use a +t1 > and put it there. And Blender as a whole isn't rebuilt, no? That > compared to uploading a new revision with a whole rebuild looks like a > win to me. Why would I upload a new revision for a single translation? > That's what I call spared buildd cycles. OK - personally, I think that translations should be reviewed by the relevant translation team on i18n.debian.net and then it can be done for you after review. Then you get that one less buildd cycle and the translation teams get a chance to fold a French translation and maybe a few others into the same +t1 upload. If maintainers do +t1 uploads, IMHO such uploads should still be coordinated with i18n.debian.net to give an opportunity for review and extra translations. I just think that, generally, maintainers have other things to do and i18n.debian.net are better suited to setting up the automation that can make +t1 uploads trivial - once reviewed. > > Between release freezes, as is covered in the DEP, maintainers are > > encouraged to use string freezes and wait for translations to be sent > > in as now - maintainers can choose to do that via the BTS if they > > want. > > Well, you can declare strings frozen, upload, and then only merge the > translations through +tN uploads, no? That means you don't have to send > them a “DEADLINE TOMORROW” to get your (non-l10n) stuff done in time. There is rarely a need for such a hurry. There is also little point in uploading new debconf questions without waiting for translations because all the current users who upgrade as soon as the upload reaches the mirrors will not have a chance to see the new question in their own language. Seeing as debconf usually only offers a question once, it negates the whole point of having translations for those users. Yes, there may be a benefit for program translations, but certainly in Squeeze+1, the emphasis is on debconf translations for TDebs and the primary use of TDebs is likely to remain debconf templates for the next few releases too. Uploads that add new debconf questions should (IMHO I'd like that to be a 'must') be delayed until such time as translators have had a chance to work on the new strings. The more important the question, the more important it is that the users get a chance to see the question in their own language and to do that properly means also getting the translation reviewed by the i18n.debian.net teams. In an ideal world, I'd like a hook in dak that traps uploads that fail a lintian-style test for untranslated debconf strings and redirects them to a queue for translation. (It would probably be a lot shorter and quicker than the NEW queue but using the same basic ideas.) Maintainers could then seek an unblock request from the release managers in the normal way or ftpmaster could decide how to proceed. It may seem draconian and there is probably a happy medium that would do the job in a more friendly way, but that is my preference. Untranslated debconf strings should be seen as bugs - serious ones at that IMHO - simply because users don't usually get a second chance with debconf. Maybe that's actually a bug in debconf but it's easier to fix by handling string freezes in a reasonable manner in the first place. (Note: this "trap" or "queue" would only operate if the new question is completely untranslated, i.e. there are no signs that the package has been even offered for translation. I've been looking at a lintian test for precisely this situation for a while, need to get back to testing it.) Anyway, that's getting ahead of ourselves again. > > > I don't want to be uploading a package each time I receive a > > > new/updated translation, so I would be using +tN uploads. Hence my > > > initial question about MU vs NMU. > > > > No, you'd be waiting for a deadline during which translations will be > > received and then you can make a single +t0 upload including all the > > updated translations *AND* the updated packages. > > As explained above, no, that sucks. And that's a huge benefit I would > see in tdebs if the usecases I presented above was actually supported > and parts of the goal of introducing tdebs. For debconf questions, it doesn't work that way - users suffer greatly from such undue haste. For program translations, it might be supported but it certainly isn't the preferred method. String freezes are not optional - all uploads involving new translatable content should wait for translations to be updated. Uploading "frozen" strings and then applying translations afterwards is just bad practice, unhelpful to users and adds unnecessary work for all involved. It should be strongly discouraged, IMHO - a last resort. > > I've got three packages in mid-string-freeze right now - 14 bugs all > > in all (another 4 translations sent direct). I'm waiting for the > > deadline to expire before I upload either the new package or the > > updated translations - one upload for each does everything. > > Well, what if you have a bug to fix? I fix it in the upload at the end of the deadline. If it is particularly severe, I'd have to branch the codebase and make an interim release from the point before the new strings were added. > Do you wait for the deadline to > expire, or do you upload at once, and only include the updated > translations in a +tN upload afterwards? No, I'd fix the bug in the previous version (i.e. a branch) and upload the fix in that version, then migrate the fix into trunk or master, depending on your RCS, and fold it into the upload that I make after the deadline has passed. It's precisely the same way as I would use when a bug is found in the current released code but the RCS version has already had significant refactoring and is not stable enough for a proper release. Missing translations are equivalent to unstable code in my own projects. If I've asked for translations and I don't get particular ones within the deadline, that's OK. However, I consider adding new strings without even offering the package for translation before uploading to be completely unacceptable behaviour. I don't see why Debian should put up with it, let alone suggest that it is "recommended" or "satisfactory". That's not part of the Specification, it's just something that I'd like people to consider whilst thinking about the Specification. Think of translations in the same manner as broken packages, even equivalent to a FTBFS. Just because l10n bugs have always been wishlist in Debian, does not mean that translation issues themselves are minor or somehow trivial. If TDebs provide a way to take the burden off maintainers for updating translations, maybe maintainers could consider using reasonable deadlines and string freezes when changing translatable content *before* uploading. > I would tend to do that, > instead of either: > 1. waiting and uploading. > 2. or uploading, waiting, and uploading again, a whole package. Done properly, you wait once and you upload once. If translators miss the deadline (as long as that deadline is reasonable, i.e. more than 10 days) then the translation can wait until the next upload or the start of the release freeze, whichever comes first. With TDebs, there is the option to do a single TDeb upload at some mid-point - but it should not be seen as a repeat method, TDebs are not meant to get to +t67. +t2 or +t3 is about the most that should be seen because the uploads should be coordinated with i18n.debian.net. > > There's no point making 30 TDeb uploads for 30 translations - set a > > reasonable deadline (+10 days is normal) and do not upload the package > > until the deadline has expired. All done in a single upload, no > > different to how things happen now. If the issue is a security fix or > > otherwise urgent, then let i18n.debian.net handle the +t1 upload once > > the translations are ready. > > I don't want an upload per translation. I just want to avoid uploading a > new revision to include translations, if that's possible. Yes, that will be possible - preferably coordinated with i18n.debian.net so that they don't need to do a +t2 the week after. > > If you receive translation updates after the deadline, liaise with > > i18n to see if there are any other updates pending, whether you've got > > an update for the package itself, all those kind of things. There's no > > need to make repeated TDeb uploads. > > Yes, spare revisions. Say a revision, then a tdeb upload once the > deadline's passed, and another round, if needed, a week or two > afterwards. I'd much prefer if it was: call for updates, full upload with +t0 tdeb after the deadline and a +t1 done by i18n.debian.net a few weeks after the deadline, if necessary. Uploading the revision before the deadline has expired is not good practice IMHO. > > What matters now is the rest of the DEP related to toolchain support > > and the format itself. How maintainers use the system and what happens > > after Squeeze is not directly relevant at this stage. > > Well, how it'll used later *is* relevant so that we can figure out which > usecases there are, why, and what features are needed to fulfill those > goals. Rather than defining a format, and then figuring out what to do > with it. Yes, as long as the use cases and configuration issues don't bog down the actual groundwork upon which they rely. There needs to be some discussion of the general case, yes, but the main issue is to get the framework agreed and then build the tools around the framework. Whatever happens, I hope that all maintainers will see the need for delaying uploads, using string freezes, setting reasonable deadlines and coordinating with i18n.debian.net when it comes to translation issues, *especially* for debconf. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpUbGpeecbY2.pgp
Description: PGP signature