Quoting Cyril Brulebois (kibi@debian.org): > > 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'll answer to this bit of Cyril's mail but that mostly covers his general points. If I follow properly, Cyril is wondering whether +tN uploads could be maintainer uploads or should only be the "privilege" of i18n folks. Neil presents an idealistic view where +tN uploads would be "better" handled with the i18n infrastructure. I think we will need at least a transition phase here, where there will be good reasons for +tN uploads by maintainers to be possible *and even wished*. And maybe that "transition phase" could last forever. In general, I don't think there is much added value in explaining who does what upload.....except of course that the +t0 upload is done by the package maintainer (or the NMU uploader in case of "regular" NMUs). In general, I would say that the spirit of the whole tdeb proposal is not necessarily to make l10n NMUs easier or not. After all, they work and we could continue without changing much stuff. The benefit of the tdeb proposal wrt l10n uploads is avoiding the trigger of package rebuilds and all associated "risks" as well of course as opening the door for a less risky and more "automated" way to make l10n updates (it will though take time before this happens as we have nothing for this right now!). > > 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™. Other benefits mught be sumarized to: - easily allow l10n updates to stable (not only debconf but also most gettext-based l10n for native packages) - even allow "regular" maintainers (understand the non i18n folks) to cope with incoming l10n updates without fearing the whole rebuild of their packages (particularly in freeze steps) - for the entire project, make it easier to cope with the ever increasing load added by l10n Neil, I think that the proposal might maybe put more focus on the benefits of the tdeb proposal for the average maintainer. The questions we've seen as of now probably show that there is a need for this. The spec itself is a very hairy document that apparently does not make it clear enough what is tried be be achieved. I even got remarks on IRC (Josselin Mouette in the French devel channel) that the proposal doesn't cope well with intltool-based i18n'ed material (such as XML files or .desktop files, or whatever). That's probably true but can come later anyway. > 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. I think that this part of Cyril's mail properly sums it up.:-) Being technical folks, we tried to setup something that would be technically hard to defeat. That's also probably needed in the Debian world where proposals without enough thoughts put on technical analysis do not generally receive much attention... However, at the point we reached now, we probably have made it clear enough that the technical grounds of tdebs are solid enough for putting on our marketing suits and try better "selling" the idea...:-) For instance, we could better explain that the concept of tdeb is not necessarily restricted to l10n material, after all. It is just a matter of allowing some files in packages to be updated separately from the rest of the package. I have no other use cases in mind right now but I'm confident in the cleverness of Debian folks to find some potential we never imagined in the whole concept..:-)
Attachment:
signature.asc
Description: Digital signature