On Tue, 14 Apr 2009 21:10:16 +0200 Cyril Brulebois <kibi@debian.org> wrote: > Neil Williams <codehelp@debian.org> (14/04/2009): > > > Any reason not to make that “sourceful uploads”? > > > > Well, the maintainer will be making the initial TDeb upload > > (effectively +t0) so the restriction does normally only affect > > non-maintainer uploads. > > > > 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. > 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. > > I suppose the maintainer might be the one doing the +t1 upload in > > order to avoid a source rebuild during a release freeze - but I can't > > say whether that's going to be particularly common. > > 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." The transition referred to there is the toolchain being made ready to handle TDebs. 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. 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. > 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. > > (If the maintainer did a string freeze before the upload that went > > into testing prior to the release freeze, it shouldn't be necessary.) > > There might be cases where a debconf question needs to be changed > > without needing any changes in the source package itself and if that > > happens during a release freeze then the maintainer could be the one > > to do it - can't see that happening that often. > > 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. A common mistake is to upload the changed package before getting the translations - even during a release cycle, this can be handled more smoothly within i18n.debian.net. 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. 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. 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. +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. 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? > > 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. 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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp4zVrn2ZAoj.pgp
Description: PGP signature