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 > > > 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? > > 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. > 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™. > The maintainer can always merge the translations into the next upload > but that would be a source rebuild - the benefit of TDebs arises > during release freezes where the source should not be changed. > > If maintainers want to help i18n with +t1, that's fine but in a > release freeze, it will still be a +t1 to prevent changes to the source > package. > > > 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. > > eventually letting the last revision age in unstable, lowering the > > pressure on the translators since translations could still be sent and > > incorporated while the buildds are doing their job, and while the > > package is aging. > > 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. > > 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. > 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? 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? I would tend to do that, instead of either: 1. waiting and uploading. 2. or uploading, waiting, and uploading again, a whole package. > 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. > 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. > +t1 uploads are principally for use during a release freeze, the other > benefits of TDebs are for use between release freezes. I don't expect > maintainers to be making +t1 uploads. I don't see why. I already told you why one would want to. > In due course, the translations are expected to be handled almost > completely within i18n.debian.net and the maintainer won't necessarily > get any translation updates sent during a release freeze, the upload > can just happen by a nominated member of the i18n.debian.net team. > There's no point clogging the BTS with lots of bug reports if there is > a simpler and more direct method to upload the updates directly from > the translation teams. Why wait for the maintainer? People still send stuff directly to the maintainers. Believe it or not, it's sometimes hard to monitor all policy/workflow/whatever changes when one isn't deeply involved in packaging (read: a random translator). And I want to be able to upload such a translation without issuing a new revision. > > > Might be better to document that later in the Specification rather > > > than in the abstract. > > > > No. > > > > Clarifying the actual intent in the abstract looks like a must to > > me. Do you want to make it trivial and costless to add/update > > translations, or do you only want to avoid l10n-only NMUs? > > I want to take the burden off maintainers and give the work to > translators to make it easier and more direct to get an updated > translation into the release. > > Anyway, all that can wait until after Squeeze - all facets related to > how uploads actually happen can be deferred because TDebs cannot be > created until after Squeeze. Well, advance discussion instead of rushing at the very last moment seems like something we should aim at… > 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. But maybe I'm totally clueless about how a specification process works. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature