Re: NMUs applying sleeping wishlist bugs about translation (was something else)
On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> * Martin Quinson (firstname.lastname@example.org) wrote:
> > On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote:
> > Dude, translators already more than this. When I translate a package, I
> > register to its PTS to check that my translation does not trigger any
> > "translation bug report".
> I'm not special caseing translations, nor do I feel they should be. I'm
> referring to NMU's in general.
Maybe that's the point. Christian won't handle the same way non translation
bugs, because the changes implied are bigger and possibly more intrusive.
> > Of course, translators can only do that for the package whom they translate
> > the po files or documentation. People translating the debconf templates feel
> > often responsible for a few hundreds of them. The lack of i18n tag to bug
> > reports makes it impossible for them to watch the state of their work
> > efficiently that way.
> This hasn't got anything to do with NMU's.
With NMU in general, maybe not. But I see this as rather relevant to the
kind of NMU we are talking about. If we add such tag, translators could
follow the result of their work. Same thing for NMUer of translations.
> > For NMU, I know that Christian tracks every NMUed packages until the next
> > maintainer upload, to check that his changes are not broken or ignored. If
> Yet he admits that he can't actually maintan the packages he uploads via
> an NMU. That's what I have a problem with.
Well, he said that he cannot handle any kind of bugs rising in any kind of
package. Yet, he can handle any kind of issue related to l10n and a bunch of
> The RM is the one who said we should be "taking more care doing NMUs
> than doing your own packages".
And that's exactly what is done here. We are not speaking of automated mass
NMU, but manual carfull and as rare as possible ones, with tracking the
future of the package afterward. I understand your point about what could be
an NMU fest, but this is not the case. The procedure *is* followed (beside
the fact that they imply wishlist bugs).
> I've pointed out numerous times in this thread already why it's wrong to
> believe that you can NMU a package without having any responsibility to
> it afterwards, except maybe for the bits you changed. Having that kind
> of an attitude is detrimental to the distribution as a whole.
Fully agreed. Who behave so badly ?
> > > A patch would probably still be easier, but whatever.
> > No offense intended, but this statement clearly shows a misunderstanding of
> > the issues the russian (and japaneese) translators are facing. If they
> > provide a simple patch, it is almost certain that the maintainer with
> > extract it from the mail and apply it with tools not well suited to the
> > weird encoding they need, leading to catastrophic results such as
> > undisplayable texts on user boxes, which is even worst than untranslated
> > ones, isn't it?
> patch won't handle it properly? Attaching the patch to a mail message
> instead of including it directly doesn't work? Funny, I recall applying
> a patch for OpenLDAP using just such a mechanism without having a
Well, either you were lucky, or you use good and well configurated mail
tools. But if my language did need a funky encoding, I would not let my work
depend of such conditions. Don't get me wrong. I mean that in such
condition, uuencoding prevents the DD from shouting himself in the foot, and
I've the feeling that it helps anyone, including the developer.
> So you're talking about it actually being a patch just uuencoded? That
Err. Yes, that's what I meant. I may say it wrong, though. Sorry about that.
> > Who, beside you, spoke of raising the gravity of translation bugs to RC ?
> > Christian certainly meant that the normal gravity may be better appropriated
> > to such bugs, since it *does* make the package unusable under some
> > conditions (when the user cannot speak english, obviously).
> I'm tired of having to repeat for you what's been said in the thread.
> Try reading it before you attempt to comment on it. Christian said:
> > The key point, as usual, is the "wishlist" status of translation bug
> > reports. I, as a non native english speaker, do not consider
> > translation to be only a "wish", but a requirement.
> I considered 'requirement' to be 'RC' level. He didn't disagree.
I did read this mail. He did not agree either. Christian did say that he
felt that discution leaded to nowhere because of radical opinion divergence,
and that he prefered not to continue.
So, once again, nobody here is threating to open RC bugs against all
packages not translated in a given language. Nobody even spoke of opening
bugs because a given program is not translated.
That would be stupid, and that will not be done.
One of the reason is that RC means: "if this bug is not fixed, Debian should
not distribute the package. At all." (bts-howto). Translation bugs are only
sufficient to make the package useless for a subset of its potential users.
But we do fill (wishlist) bugs when we did translate a part of the package,
and then, when the translation rots in the BTS, we feel ok to NMU the
package for that (as long as the procedure is respected).
> > Stating the contrary may be bring down to the point that free software is
> > about making software freely available (as in free speach) to the american,
> > british and autralian people on the earth, plus some elites of the other
> > countries having the chance to speak more than one language fluently enough
> > to use an english speaking computer. To that extent, MS and apples systems
> > are much more opened to new commers than debian is.
> You're implying that we cannot consider software 'free' unless it's
> translated to every language. If you want to consider down this road
> then consider that the majority of english speakers don't know C, or
> C++, or any other programming language. Of course, the reality is that
> the software being 'free' or not is a function of the license and not
> what language it's written in, programming or otherwise.
Not, I only mean that a whole amount of free software (as speach) aren't
available to non english speaker. They are free, no doubt. But useless for
70-80% of the earth population. What a pitty.
I don't want to do the revolution, but to find ways to get this fixed.
> > *** we do not want to change this ***. Yet ;) It is just to give you the
> > point of view of most badly english speaking linux users.
> You're attempting to equate things which are different and seem to be
> implying, like Christian was, that translations should be RC-level.
Don't worry, I'm not.
> My concern is with people not taking responsibility when they NMU.
Christian does. The point is that we don't seem to be able to agree of what
the responsabilities of NMUers are, You say that NMUing is like hijack for a
limited amount of time, and we say that NMUing to fix a perticular point of
the packaging not related with the program inside the package may be ok as
long as the NMUer watch the package afterward to see if his changes trigger
*related* issues or not.
> > How about porters, uploading versions of the package for other
> > architectures? Do they become responsible for every bug reported by user of
> > this perticular architecture, even if it is not specific to the given archi?
> binary-only uploads are clearly not the same.
Ah ? And why ? Translation changes do not interfer with the source code of
the package neither.
Technically, it could be possible to use an overide system to put the result
of the translator work into the binary package a few days after its upload
by the maintainer (when the translator is done) without breaking anything.
Naturally this would imply to bump the third (or a fourth) part in the
package version number. But this has yet to be done.
PS: I'm already subscribed to the list, thanks for the ccing.
Ian Fleming was a UNIX fan! How do I know?
Well, James Bond had the (license to kill) number 007,
i.e., he could execute anyone!