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

Re: DEP-4 TDebs - updated

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"

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

Reply to: