On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote:
> * Christian Perrier ([EMAIL PROTECTED]) wrote:
> > Quoting Stephen Frost ([EMAIL PROTECTED]):
> >
> > > > I, for sure, cannot hijack any package for which nothing has been done
> > > > for translation related bugs. I would quickly end up with dozens of
> > > > packages I'm responsible for, the majority of which I'm perfectly
> > > > unable to maintain.
> > >
> > > If you can't maintain the package then you shouldn't be NMU'ing it.
> > > It's real simple, learn that.
> >
> > Wow....There's a strong difference between maintaining a package,
> > which means following it along its entire life and making one single
> > fix for a very specific thing.
>
> 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".
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 ;)
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.
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.
> > I'm perfectly able to do the changes required by the NMU i send,
> > mostly po-debconf switches or translation incormoration. But, if a bug
> > related to something completely different in the package occurs, then
> > I cannot fix it be cause I'm not invloved in the given software.
>
> 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...
> > 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.
> > They're not complex at all. Most of the time (for russian
> > translations), it is just required to know how to uudecode file and
> > how should a debconf translation be named... :-)
>
> 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?
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.
> > 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).
Let's be provocative:
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.
*** 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.
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.
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.
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?
Thanks for your time, Mt.
--
I'm not griping, I'm just observing what a miserable experience this is.
--- Calvin
