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

Re: NMUs applying sleeping wishlist bugs about translation (was something else)



* Martin Quinson (martin.quinson@tuxfamily.org) wrote:
> On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote:
> > Except what you don't realize is that one should never, ever, ever just
> > NMU and then forget about the package.  If you do an NMU then you need
> > to make sure it worked, follow the package and make sure there aren't
> > problems with it and follow up with the maintainer on the bugs.  I don't
> > care what you change in the package, if you NMU then you need to do that
> > at a *minimum*, just as if you were the maintainer.  It's not until the
> > official maintainer incorporates the NMU changes and closes the bugs
> > that the NMU'er can forget about it.
> 
> 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.

> Are you one of the guys considering translators as a technically handicaped
> plague of the Debian world? I know that most of the time, the problem is
> between the screen and the chair, but that's not always the case ;)

Are you one of the guys who tries to put words in the mouths of others
with the intent to reduce their credibility when they've said nothing
anything like what you infer?

> 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.

> 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
> you speak some french, come on debian-l10n-french for one week, to see the
> logistic issues we are facing, and how we address them. If you speak another
> language, go to the relevant debian-l10n- list, I'm sure that the french
> team is not an exception here, but rather the average.

Yet he admits that he can't actually maintan the packages he uploads via
an NMU.  That's what I have a problem with.

> > Then you shouldn't be doing an NMU on it.  When you NMU something you
> > take responsibility for it temporairly until the maintainer gets back.
> 
> Could you point the poor stupid monkeys we are to the relevant part of the
> policy or developer reference or whatever other document ? I really do not
> understand what let you think about NMU that way, especially after the last
> bits of the RM...

The RM is the one who said we should be "taking more care doing NMUs
than doing your own packages".

> > > For what I read, it is not required to be able to maintain everything
> > > for a given package for being able to NMU it. It is just required to
> > > be able to fix possible introduced bugs....
> > 
> > Then what you read is wrong.
> 
> Again, why? Stating without argumenting will only bring us in yet another
> fruitless flamewar. Please help us avoiding that curse.

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.

> > 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
problem.

> On the other hand, uuencoding the patchs helps to make sure that the
> encoding will be preserved by the stupid mailers and wrong configurations
> out there.

So you're talking about it actually being a patch just uuencoded?  That
doesn't seem to agree with what you were saying earlier.  Personally I'd
probably be annoyed to have a patch uuencode'd instead of in the mail as
a MIME attachment.

> > > This is precisely what's currently happening.. :-)
> > 
> > Glad to hear it, perhaps some day you will, though personally I hope to
> > hell you never manage to get it considered an RC bug, and I'll work to
> > make sure that doesn't happen.
> 
> 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.

> Let's be provocative: 

This isn't provocative, it's rather foolish.

> 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.

> *** 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.

> Once again, please note that even if we feel the current gravity of the
> translation bugs unfair, none of us ever submitted such a bug with another
> gravity. It was not even the purpose of the discusion, but rather how to
> help the roting translation bugs from the BTS getting integrated where they
> should.

My concern is with people not taking responsibility when they NMU.

> Instead of sliping on the dark (and easy) side of the flamewar, please point
> me to the relevant part of the documentation stating that NMUer are
> responsible to any bug appearing in the package after their NMU, even
> unrelated to the changes they introduced. I mean of course *more*
> responsible than any other DD since you are all responsible of all bugs in
> Debian, to some extents.

NMUers are responsible for packages they NMU.

> 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.

	Stephen

Attachment: pgpY9lxD0joAQ.pgp
Description: PGP signature


Reply to: