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

[Steve Langasek]

On Wed, Aug 27, 2003 at 02:57:28PM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > Holding NMUers accountable for the quality of their uploads: yes.
> > Holding NMUers accountable for the quality of the maintainer's package: no.

> I'm happy to clarify my position if you aren't clear on it and would
> rather you do that then make misleading claims.  I don't know how NMUers
> could be *more* accountable than the official maintainer.  My position
> is that they should be equally responsible for bugs in the package,
> until the maintainer does an upload. 

Which is what I understood your position to be, and which is the
position I disagree with.  I'm sorry if you feel I've misrepresented
your views in some way.

I suppose I can concede that an NMUer should be as responsible as the
maintainer -- to the extent that, if the package is being NMUed, the
maintainer usually isn't taking all that much responsibility for the
package at the time, so the bar isn't set very high. ;P

-- 
Steve Langasek
postmodern programmer


pgpDibU2A3LML.pgp
Description: PGP signature

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

[Sven Luther]

On Wed, Aug 27, 2003 at 11:46:41AM -0500, Steve Langasek wrote:
> On Thu, Aug 28, 2003 at 12:31:30AM +1000, Anthony Towns wrote:
> > On Wed, Aug 27, 2003 at 09:35:08AM +0200, Sven Luther wrote:
> > > It only means that someone
> > > wanting to do an NMU for some probably minor, not really touching the
> > > package, will not do it because he don't want that responsaibility or
> > > more probably cannot assume it. 
> 
> > That's the correct response. If you can't handle the responsibility you
> > shouldn't be touching other people's packages; you should be sending
> > the maintainer patches through the BTS. If someone who can handle the
> > responsibility of NMUing comes along and sees the patch before the
> > maintainer gets around to it, that's all to the good.
> 
> > > No need to attribute
> > > responsabilities to people who possibly cannot fullfill them.
> 
> > If you can't cope with -- ie, resolve -- the possible problems from NMUing,
> > you should not be NMUing.
> 
> This is the sticking point, I think.  Are we talking about resolving the
> possible problems *from* NMUing, or are we talking about resolving any
> problems that happen to show up after the NMU?  I absolutely agree that
> an NMUer is responsible for fixing any problems caused by the NMU, but I
> don't agree that NMUers should be held responsible for pre-existing bugs
> in the package -- whether or not they happened to be exposed by the
> NMU in question.
> 
> I think that it's generally very silly for someone to NMU a package if
> they don't care enough about it to want to try to resolve any RC bugs
> that show up and keep the package out of testing; but I don't like the
> climate of blame that Stephen Frost's posts seem to be promoting.  He
> seems to suggest that NMUers be held even more accountable than the
> packages' maintainers:  the worst that happens to a maintainer is that
> he doesn't get to see his package included in the stable release, but it
> sounds like NMUers are going to be roasted three ways from Sunday for
> bugs they didn't actually cause.  If that's the case, I have no
> inclination whatsoever to NMU buggy packages -- I'd much rather file for
> their removal from the archive.

BTW, that would be another way of achieving full translation of all
packages in a release, remove all them that don't quickly enough apply
the transition patch :)))

Friendly,

Sven Luther

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

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> Holding NMUers accountable for the quality of their uploads: yes.
> Holding NMUers accountable for the quality of the maintainer's package: no.

I'm happy to clarify my position if you aren't clear on it and would
rather you do that then make misleading claims.  I don't know how NMUers
could be *more* accountable than the official maintainer.  My position
is that they should be equally responsible for bugs in the package,
until the maintainer does an upload. 

This also isn't to say they have to be able to fix every bug in the
package but like the maintainer they need to try and tag it help, etc.
Additionally, any DD should also have the ability to request a package 
be removed or orphaned to QA if it's clearly not being maintained.  The
same goes for hijacking packages but I think most understand that
already.

Stephen


pgpGC4OIlpTuc.pgp
Description: PGP signature

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

[Steve Langasek]

On Thu, Aug 28, 2003 at 12:31:30AM +1000, Anthony Towns wrote:
> On Wed, Aug 27, 2003 at 09:35:08AM +0200, Sven Luther wrote:
> > It only means that someone
> > wanting to do an NMU for some probably minor, not really touching the
> > package, will not do it because he don't want that responsaibility or
> > more probably cannot assume it. 

> That's the correct response. If you can't handle the responsibility you
> shouldn't be touching other people's packages; you should be sending
> the maintainer patches through the BTS. If someone who can handle the
> responsibility of NMUing comes along and sees the patch before the
> maintainer gets around to it, that's all to the good.

> > No need to attribute
> > responsabilities to people who possibly cannot fullfill them.

> If you can't cope with -- ie, resolve -- the possible problems from NMUing,
> you should not be NMUing.

This is the sticking point, I think.  Are we talking about resolving the
possible problems *from* NMUing, or are we talking about resolving any
problems that happen to show up after the NMU?  I absolutely agree that
an NMUer is responsible for fixing any problems caused by the NMU, but I
don't agree that NMUers should be held responsible for pre-existing bugs
in the package -- whether or not they happened to be exposed by the
NMU in question.

I think that it's generally very silly for someone to NMU a package if
they don't care enough about it to want to try to resolve any RC bugs
that show up and keep the package out of testing; but I don't like the
climate of blame that Stephen Frost's posts seem to be promoting.  He
seems to suggest that NMUers be held even more accountable than the
packages' maintainers:  the worst that happens to a maintainer is that
he doesn't get to see his package included in the stable release, but it
sounds like NMUers are going to be roasted three ways from Sunday for
bugs they didn't actually cause.  If that's the case, I have no
inclination whatsoever to NMU buggy packages -- I'd much rather file for
their removal from the archive.

Holding NMUers accountable for the quality of their uploads: yes.
Holding NMUers accountable for the quality of the maintainer's package: no.

-- 
Steve Langasek
postmodern programmer


pgpnDmZZA1Ro7.pgp
Description: PGP signature

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

[Anthony Towns]

On Wed, Aug 27, 2003 at 09:35:08AM +0200, Sven Luther wrote:
> It only means that someone
> wanting to do an NMU for some probably minor, not really touching the
> package, will not do it because he don't want that responsaibility or
> more probably cannot assume it. 

That's the correct response. If you can't handle the responsibility you
shouldn't be touching other people's packages; you should be sending
the maintainer patches through the BTS. If someone who can handle the
responsibility of NMUing comes along and sees the patch before the
maintainer gets around to it, that's all to the good.

> No need to attribute
> responsabilities to people who possibly cannot fullfill them.

If you can't cope with -- ie, resolve -- the possible problems from NMUing,
you should not be NMUing.

And there are plenty of people who are interested in translations and
who are competent to NMU.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpeQPWkIqhTY.pgp
Description: PGP signature

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

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> with not only translating abilities (in fact I'm even rather bad at
> translating).

That's fine, I'm rather bad at programming... :-)

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

[Martin Quinson]

On Tue, Aug 26, 2003 at 07:28:03PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> > Let's say i do translataion work, for that i have to build the package,
> > and notice that it FTBFS (at least on some obscure arch or something). I
> > then fill a FTBFS bug report, thus liberating me of the responsability
> > you want to trust on me, and then NMU the translation improved package.
> 
> Uh, no. If it liberates you of anything, it'll likely be your ability to
> do any more NMUs.
> 
> If the package is less useful to people after you do the NMU than before
> you started looking at it, that's a problem. If it was formerly able
> to be run by everyone no matter which architecture, and now no longer
> works on alpha, that's a problem.


If I were in Christian shoes facing such issue (dormant l10n bug, but the
rebuild triggers a FTBFTS), I would report the FTBFTS, and look at another
package (ie, not doing the NMU if he obviously cannot do it right). 

If it's too late already (ie, the FTBFTS is trigered by build daemons on
alpha or other), I will go cry on debian-l10n-french or other to get some
help. I am coordinator of the french l10n, but in the civilian, I work on
massively heterogeneous platforms (yup, da grid). So, I guess I could try to
work around such issues. I know some perl semi-gods in the team. Other
members may be good at libraries puzzles.

As we work heavily in team, we know that the responsability of fixing the
mess we introduce in NMUs is ours. Not only Christian's, but ours. And our
chance is that there is many of us, all wanting to get a better l10n, but
with not only translating abilities (in fact I'm even rather bad at
translating).


Little need to worry about who's responsability it is to fix the mess, it
has to be done, that's all.

Thanks for your time, Mt.

-- 
Un clavier azerty en vaut deux.

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

[Sven Luther]

On Wed, Aug 27, 2003 at 02:31:51PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 09:28:02PM +0200, Sven Luther wrote:
> > I agree if the FTBFS comes from something the NMUer did, then yes, it is
> > broken, but if it comes from general bad shape of the packages, then the
> > responsability is to the package maintainer
> 
> It's fine that you disagree. You're welcome to that. If you're going to
> act on your opinions though -- and not take responsibility for fixing
> the new bugs found when you upload NMUs -- then please do not NMU.

No problem, i take responsability of the packages i NMU, it is just that
i don't think this attititude is correct. It only means that someone
wanting to do an NMU for some probably minor, not really touching the
package, will not do it because he don't want that responsaibility or
more probably cannot assume it. So, he will not do it, and the possible
FTBFS will not be discovered. As said, i don't do translations, so this
doesn't touch me.

> Again: this isn't about finding fault, it's about taking responsibility
> for the quality of your NMUs, and making sure that *all* new problems
> are resolved whether you caused them or not.

I understand that for the aim of having sarge release on december 1, it
is good for people to feel responsible for broken packages. I have
another solution for this : if the package potentially FTBFS, the
maintainer is either MIA or doesn't care, and nobody (be he NMUer or
not) cares enough to fix the FTBFS, then just remove the package from
the archive, or at least from sarge. No need to attribute
responsabilities to people who possibly cannot fullfill them.

Friendly,

Sven Luther

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

[Anthony Towns]

On Tue, Aug 26, 2003 at 09:28:02PM +0200, Sven Luther wrote:
> I agree if the FTBFS comes from something the NMUer did, then yes, it is
> broken, but if it comes from general bad shape of the packages, then the
> responsability is to the package maintainer

It's fine that you disagree. You're welcome to that. If you're going to
act on your opinions though -- and not take responsibility for fixing
the new bugs found when you upload NMUs -- then please do not NMU.

Again: this isn't about finding fault, it's about taking responsibility
for the quality of your NMUs, and making sure that *all* new problems
are resolved whether you caused them or not.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpAgaWnwYZlR.pgp
Description: PGP signature

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

[Sven Luther]

On Tue, Aug 26, 2003 at 07:28:03PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> > Let's say i do translataion work, for that i have to build the package,
> > and notice that it FTBFS (at least on some obscure arch or something). I
> > then fill a FTBFS bug report, thus liberating me of the responsability
> > you want to trust on me, and then NMU the translation improved package.
> 
> Uh, no. If it liberates you of anything, it'll likely be your ability to
> do any more NMUs.
> 
> If the package is less useful to people after you do the NMU than before
> you started looking at it, that's a problem. If it was formerly able
> to be run by everyone no matter which architecture, and now no longer
> works on alpha, that's a problem.

And you don't care that it FTBFS ? If it FTBFS, then the package is
broken, and knowing this is better than not knowing this. and how in
hell can this be the responsability of the NMUer, if it FTBFS even
before he touched the package.

I agree if the FTBFS comes from something the NMUer did, then yes, it is
broken, but if it comes from general bad shape of the packages, then the
responsability is to the package maintainer, and failing that (if he is
MIA or otherwise unresponsive) the responsability of the QA team or the
debian devels in general, not particularly the translators.

Friendly,

Sven Luther

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

[Anthony Towns]

On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> Let's say i do translataion work, for that i have to build the package,
> and notice that it FTBFS (at least on some obscure arch or something). I
> then fill a FTBFS bug report, thus liberating me of the responsability
> you want to trust on me, and then NMU the translation improved package.

Uh, no. If it liberates you of anything, it'll likely be your ability to
do any more NMUs.

If the package is less useful to people after you do the NMU than before
you started looking at it, that's a problem. If it was formerly able
to be run by everyone no matter which architecture, and now no longer
works on alpha, that's a problem.

> And then, how can the NMUer in this case be responsible for some poorly
> maintained package to FTBFS ? just because he happened to do some
> translation work for it ?

If you NMU a package you need to take responsibility for making that
package work. If you don't want to do that, don't NMU, just submit a patch
instead. If the patch doesn't go in for weeks or years, that's too bad;
that's the difference between doing QA work -- making NMUs and taking
responsibility for your uploads -- and submitting useful feature requests.

> Or are we going to get afraid of making bugfixes or something because a
> given unmaintained package possibly might FTBFS, and we will not trigger
> it. 

You shouldn't be afraid of bugs, you should fix them.

It's really that simple.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgp9pTek4jDgu.pgp
Description: PGP signature

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

[Christian Perrier]

Quoting Sven Luther ([EMAIL PROTECTED]):

> And i i try to build a random package from source, and it FTBFS, am i
> going to be responsible for fixing it if i fill the FTBFS bug report ?

For sure, no. In the example previously given, I did generate the
FTBFS myself by uploading a NMU. I indirectly made the package having
the RC bug. And it's probably impossible to go back...

This is for sure too bad for me, no luck

In your example, I am just the bug reporter and the package in the
distribution is still "working". 

The difference is very subtile, anyway...and in both cases, because I
am a responsible DD who cares about the distribution, I will make by
best for fixing the bug or help fixing it.

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

[Sven Luther]

On Tue, Aug 26, 2003 at 10:10:31AM +0200, Christian Perrier wrote:
> Quoting Anthony Towns (aj@azure.humbug.org.au):
> 
> 
> > Tagging the bug help is a good idea, but if it doesn't work the
> > responsibility is *still* the NMUer's to find some way that does. Not
> > the community's, not the list's, not the release manager's: the NMUer's.
> 
> I undoubtly agree with that pointNot with Stephen Frost's point,
> however.
> 
> If my NMU raises a portability issue (previously hidden), I *am*
> responsible for dealing with it.

And i i try to build a random package from source, and it FTBFS, am i
going to be responsible for fixing it if i fill the FTBFS bug report ?

Friendly,

Sven Luther

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

[Sven Luther]

On Tue, Aug 26, 2003 at 02:53:50PM +1000, Anthony Towns wrote:
> On Mon, Aug 25, 2003 at 05:34:54PM +0200, Sven Luther wrote:
> > On Mon, Aug 25, 2003 at 07:10:19PM +1000, Anthony Towns wrote:
> > > On Mon, Aug 25, 2003 at 07:22:16AM +0200, Christian Perrier wrote:
> > > > Quoting Martin Quinson ([EMAIL PROTECTED]):
> > > > > > binary-only uploads are clearly not the same.
> > > > > Ah ? And why ? Translation changes do not interfer with the source 
> > > > > code of
> > > > > the package neither.
> > > > Hummm. Technically speaking, it does..?:-). With the source code of
> > > > the packagenot with the upstream source code.
> > > New uploads will often trigger dormant bugs due to changes in the
> > > toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
> > > current, a new upload built with gcc-3.3 will often not work even if the
> > > only source changes were some grammar corrections in a README file, eg.
> > > 
> > > It's the NMUer's responsibility to fix these bugs too.
> > Err, FTBFS are RC bugs, most probably not of the responsability of the
> > NMUer. 
> 
> No. They're most probably not through any *fault* of the NMUer. Nevertheless
> they are *still* the *responsibility* of the NMUer.
> 
> > What would you say if instead of doing the NMU, the potential uploader
> > would will a FTBFS RC bug, and then make an NMU which fixes the
> > translation problem. Would it then still be his responsability to fix
> > the FTBFS bug ?
> 
> I don't understand what you're saying. "would will a FTBFS RC bug" ?

Ok, i explain more in detail.

Let's say i do translataion work, for that i have to build the package,
and notice that it FTBFS (at least on some obscure arch or something). I
then fill a FTBFS bug report, thus liberating me of the responsability
you want to trust on me, and then NMU the translation improved package.

How can then the responsability be on the NMUer, if it was already
present before ?

And then, how can the NMUer in this case be responsible for some poorly
maintained package to FTBFS ? just because he happened to do some
translation work for it ?

Or are we going to get afraid of making bugfixes or something because a
given unmaintained package possibly might FTBFS, and we will not trigger
it. For that matter, i guess people are now afraid to build packages,
because of the new glibc being broken and holding everything.

Disclaimer : i never did translation work, and probably never will, my
written french being not much better than my english one.

Friendly,

Sven Luther

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

[Christian Perrier]

Quoting Anthony Towns (aj@azure.humbug.org.au):


> Tagging the bug help is a good idea, but if it doesn't work the
> responsibility is *still* the NMUer's to find some way that does. Not
> the community's, not the list's, not the release manager's: the NMUer's.

I undoubtly agree with that pointNot with Stephen Frost's point,
however.

If my NMU raises a portability issue (previously hidden), I *am*
responsible for dealing with it.

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

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> Earlier if the french team reachs its goal of completely translated package
> install in sarge, since we only translate po-debconf files, and do (read

We won't.. :-)

For po-debconf switch bug reports, Michel Grentzinger is at letter "p"
going up in the alphabet. But he's a college teacher and will soon be
back to work :-)

I'm at letter "d", going down.but I go quite slowly as I also deal
with old translations sleeping in the BTS...and thus have to prepare
NMU's, subscribe to many many PTS and deal with all opened bugs of all
NMU'ed packages, including future bugs (grin).

Andre Luis Lopes, from Brazil, is also working on po-debconf switch
but I don't know how he does choose packages for which he submits
patches.

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

[Anthony Towns]

On Mon, Aug 25, 2003 at 05:34:54PM +0200, Sven Luther wrote:
> On Mon, Aug 25, 2003 at 07:10:19PM +1000, Anthony Towns wrote:
> > On Mon, Aug 25, 2003 at 07:22:16AM +0200, Christian Perrier wrote:
> > > Quoting Martin Quinson ([EMAIL PROTECTED]):
> > > > > binary-only uploads are clearly not the same.
> > > > Ah ? And why ? Translation changes do not interfer with the source code 
> > > > of
> > > > the package neither.
> > > Hummm. Technically speaking, it does..?:-). With the source code of
> > > the packagenot with the upstream source code.
> > New uploads will often trigger dormant bugs due to changes in the
> > toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
> > current, a new upload built with gcc-3.3 will often not work even if the
> > only source changes were some grammar corrections in a README file, eg.
> > 
> > It's the NMUer's responsibility to fix these bugs too.
> Err, FTBFS are RC bugs, most probably not of the responsability of the
> NMUer. 

No. They're most probably not through any *fault* of the NMUer. Nevertheless
they are *still* the *responsibility* of the NMUer.

> What would you say if instead of doing the NMU, the potential uploader
> would will a FTBFS RC bug, and then make an NMU which fixes the
> translation problem. Would it then still be his responsability to fix
> the FTBFS bug ?

I don't understand what you're saying. "would will a FTBFS RC bug" ?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpadjh4whPQH.pgp
Description: PGP signature

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

[Anthony Towns]

On Mon, Aug 25, 2003 at 03:15:25PM +0200, Christian Perrier wrote:
> Quoting Anthony Towns (aj@azure.humbug.org.au):
> > It's the NMUer's responsibility to fix these bugs too.
> 
> > (One possible way of handling this, might be to have translation people
> > support each other by having random non-coders do the l10n NMUs and
> > having a couple of bad-ass hax0rs on hand to leap to their aid should
> > they trigger some unexpected serious breakage.)
> 
> Though this is not formalized, I'm very confident that if this happens
> some day, I would without any problem find someone for helping in
> either debian-devel-french (asking there first because this would be
> easier for mutual comprehension)of here (and using the "help"
> tag on a RC bug I would raise myself for "not building from sources").

Tagging the bug help is a good idea, but if it doesn't work the
responsibility is *still* the NMUer's to find some way that does. Not
the community's, not the list's, not the release manager's: the NMUer's.

Don't stress too much over the mechanics in extreme cases -- we can
work that out when or if they ever happen. Just make sure you've got
the mindset right when the usual cases appear.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgp7U83vSGVQ3.pgp
Description: PGP signature

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

[Anthony Towns]

On Mon, Aug 25, 2003 at 04:58:31PM +0300, Richard Braakman wrote:
> On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> > Just about everyone else appears to feel all they should care about is
> > the changes they make in their NMU instead of actually caring about the
> > package and the distribution.  There's this feeling of "not my problem".
> You are berating people who are working to improve the distribution
> because they're not doing as much volunteer work as you think they
> should be doing.  That's rude.

Or, alternatively, he's working to mitigate a real, forseeable risk of
a new process we'd like to adopt, that we don't have a huge amount of
recent experience with, in as forthright a manner as he's able. This is
a perfectly reasonable and professional attitude.

Take it easy.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpS1bfkttYuo.pgp
Description: PGP signature

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

[Martin Quinson]

On Mon, Aug 25, 2003 at 01:19:57PM +0100, Mark Brown wrote:
> On Mon, Aug 25, 2003 at 01:22:03PM +0200, Christian Perrier wrote:
> 
> > With the former (and still widely used) method for translating debconf
> 
> Is anyone maintaining statistics on how widely used the original Debconf
> scheme is?

Greping around in (I love grep-dctrl)
http://ftp-master.debian.org/~barbier/l10n/material/data/unstable.gz
(used to generate w.d.o/intl/l10n) 

shows me that there is 2122 strings using old debconf and
http://www.debian.org/intl/l10n/po-debconf/rank
says that there is 3421 strings using po-debconf.

I have no historic on that data; these are the files integrated in the
packages, not counting the opened bugs not yet integrated, neither the
switches underway and not yet submitted.

So, I guess that the transition will be achieved for sarge + 1, at least.

Earlier if the french team reachs its goal of completely translated package
install in sarge, since we only translate po-debconf files, and do (read
submit as patch) the switch if needed. ;)

Bye, Mt.

-- 
Never trust someone who only codes in CAML... because the way things are
done matters more to him than the result.

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

[Sven Luther]

On Mon, Aug 25, 2003 at 07:10:19PM +1000, Anthony Towns wrote:
> On Mon, Aug 25, 2003 at 07:22:16AM +0200, Christian Perrier wrote:
> > Quoting Martin Quinson ([EMAIL PROTECTED]):
> > > > binary-only uploads are clearly not the same.
> > > Ah ? And why ? Translation changes do not interfer with the source code of
> > > the package neither.
> > Hummm. Technically speaking, it does..?:-). With the source code of
> > the packagenot with the upstream source code.
> 
> New uploads will often trigger dormant bugs due to changes in the
> toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
> current, a new upload built with gcc-3.3 will often not work even if the
> only source changes were some grammar corrections in a README file, eg.
> 
> It's the NMUer's responsibility to fix these bugs too.

Err, FTBFS are RC bugs, most probably not of the responsability of the
NMUer. Especially if the NMUer just did some translation work or
something.

What would you say if instead of doing the NMU, the potential uploader
would will a FTBFS RC bug, and then make an NMU which fixes the
translation problem. Would it then still be his responsability to fix
the FTBFS bug ?

And it is always better to fix those FTBFS bugs, than to silently ignore
them and hoping that another RC bug doesn't force us to rebuild anyway.

Friendly,

Sven Luther

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

[Steve Langasek]

On Mon, Aug 25, 2003 at 11:56:33AM +0100, Mark Brown wrote:
> On Sun, Aug 24, 2003 at 11:08:52PM +0200, Martin Quinson wrote:

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

> As a data point all the translations I've been sent since I can remember
> (certainly since I converted my packages to use po-debconf) have arrived
> as MIME attachments to bugs.  If there are any problems with their
> encoding they certainly haven't been reported to me.  If this is a
> problem it doesn't seem to be bothering many people.

> I'd certainly much rather get translations as MIME attachments since
> MIME is actually supported by mail tools and I'm not convinced there is
> actually a problem with it.

I have had the experience in the past where my MUA (mutt) running in
UTF-8 mode would *autoconvert* plaintext MIME attachments when saving
them, such that an attachment received in ISO8859-1 would be saved to
disk as UTF-8.  Given that the .po files contain embedded information
about the document's encoding, this doesn't work all that well.

The translator in question has taken to gzipping his translations when
sending them, which seems a reasonable workaround until the whole world
is running UTF8. :)

-- 
Steve Langasek
postmodern programmer


pgpj8nQpkTi3D.pgp
Description: PGP signature

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

[Richard Braakman]

On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

Someone who has a feeling of "not my problem" won't be thinking of
doing an NMU in the first place.  I present myself as Exhibit A.

Translators have an area of interest that doesn't fit neatly into
a few packages.   They're not alone in this -- porters, and people
who manage transitions, are in the same boat.  That doesn't mean
they care less, it just means they care about specific aspects
of all packages, rather than all aspects of specific packages.

You are berating people who are working to improve the distribution
because they're not doing as much volunteer work as you think they
should be doing.  That's rude.

Richard Braakman

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

[Richard Braakman]

On Sun, Aug 24, 2003 at 06:56:00PM -0400, Stephen Frost wrote:
> You've obviously not been paying very much attention at all then.
> You should have a pretty good idea if the package is unmaintained or
> not prior to doing an NMU.  If it's not then you're uploading a package
> which fixes some specific bug but leaves the package unmaintained.
> That's irresponsible.

That just doesn't make sense.  Is it somehow more responsible to
skip the NMU and leave the package with an extra bug that you
could have fixed?

Richard Braakman

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

[Christian Perrier]

Quoting Anthony Towns (aj@azure.humbug.org.au):

> New uploads will often trigger dormant bugs due to changes in the
> toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
> current, a new upload built with gcc-3.3 will often not work even if the
> only source changes were some grammar corrections in a README file, eg.
> 
> It's the NMUer's responsibility to fix these bugs too.

I agree with that, sure. In fact I fear this to appen to me some
day.. :-). But in that case :

> 
> (One possible way of handling this, might be to have translation people
> support each other by having random non-coders do the l10n NMUs and
> having a couple of bad-ass hax0rs on hand to leap to their aid should
> they trigger some unexpected serious breakage.)

Though this is not formalized, I'm very confident that if this happens
some day, I would without any problem find someone for helping in
either debian-devel-french (asking there first because this would be
easier for mutual comprehension)of here (and using the "help"
tag on a RC bug I would raise myself for "not building from sources").

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

[Anthony Towns]

On Mon, Aug 25, 2003 at 07:22:16AM +0200, Christian Perrier wrote:
> Quoting Martin Quinson ([EMAIL PROTECTED]):
> > > binary-only uploads are clearly not the same.
> > Ah ? And why ? Translation changes do not interfer with the source code of
> > the package neither.
> Hummm. Technically speaking, it does..?:-). With the source code of
> the packagenot with the upstream source code.

New uploads will often trigger dormant bugs due to changes in the
toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
current, a new upload built with gcc-3.3 will often not work even if the
only source changes were some grammar corrections in a README file, eg.

It's the NMUer's responsibility to fix these bugs too.

(One possible way of handling this, might be to have translation people
support each other by having random non-coders do the l10n NMUs and
having a couple of bad-ass hax0rs on hand to leap to their aid should
they trigger some unexpected serious breakage.)

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgp836iJdKwEb.pgp
Description: PGP signature

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

[Christian Perrier]

Quoting Mark Brown ([EMAIL PROTECTED]):

> > With the former (and still widely used) method for translating debconf
> 
> Is anyone maintaining statistics on how widely used the original Debconf
> scheme is?

I'm not aware of such statistics.

We have the total number of strings in the new schemes. It was 3423
yesterday evening. See
http://www.debian.org/international/l10n/po-debconf/rank

Unfortunately, for old-style debconf templates, Denis Barbier (who
wrote the scripts which generate several l10n pages) did not include
the count of total strings
(http://www.debian.org/international/l10n/templates/rank). I've asked
him for such count a few days ago...but Denis is currently VAC so this
will have to wait until he comes back.


I expect to be still much more strings in old-style debconf than in
new-style.

On the other hand, the majority of key packages has already switched
to po-debconf

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

[Mark Brown]

On Mon, Aug 25, 2003 at 01:22:03PM +0200, Christian Perrier wrote:

> With the former (and still widely used) method for translating debconf

Is anyone maintaining statistics on how widely used the original Debconf
scheme is?

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

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

[Christian Perrier]

Quoting Mark Brown ([EMAIL PROTECTED]):

> As a data point all the translations I've been sent since I can remember
> (certainly since I converted my packages to use po-debconf) have arrived
> as MIME attachments to bugs.  If there are any problems with their
> encoding they certainly haven't been reported to me.  If this is a
> problem it doesn't seem to be bothering many people.

po-debconf helps a lot there, because all you have to do is drop the
xx.po file in debian/po.

With the former (and still widely used) method for translating debconf
stuff, with templates.xx files along with the master templates files
or, even less easier, all translations in the same file, it was quite
easy for maintainers to mess up translations.

This is why, for instance, Ilgiz Kalmetev sent his old russian
translations for templates uuencoded. He does not do so anymore when
sending ru.po files because that isn't needed.

In this matter, for sure, po-debconfhas been a major
enhancement. Thanks to Denis Barbier and Joey Hess who made this
possible.

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

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> Thanks for your time. I do really appreciate the time you're investing in a
> discussion which is vital for my presonal goals inside Debian, but clearly
> not for yours.

I think we cannot say this from Stephen's mail. We clearly disagree on
NMU/reponsibility stuff but, so far, Stephen has never mentioned that he
has no interest in translation stuffat least from what I've interpreted... 

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

[Mark Brown]

On Sun, Aug 24, 2003 at 11:08:52PM +0200, Martin Quinson wrote:

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

As a data point all the translations I've been sent since I can remember
(certainly since I converted my packages to use po-debconf) have arrived
as MIME attachments to bugs.  If there are any problems with their
encoding they certainly haven't been reported to me.  If this is a
problem it doesn't seem to be bothering many people.

I'd certainly much rather get translations as MIME attachments since
MIME is actually supported by mail tools and I'm not convinced there is
actually a problem with it.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

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

[Christian Perrier]

Quoting Stephen Frost ([EMAIL PROTECTED]):

> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

I have to correct here : when considering a NMU (or even doing it), I
nearly always look at the BTS just to see whether this particular
package doesn't have any other bugs which I could easily fix, with my
(limited) knowledge.

I wouldn't call this "not my problem"... :-)

BUT, of course, as I'm not Superman, I most often cannot deal with all
already opened bugs. I would rather call this "I cannot endorse all
world problems"


> > 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.
> 
> You, again, didn't read the thread.  No one said anything about
> threating to open RC bugs, etc, etc.  There was, however, a discussion
> about the possibility of changing the severity level at some point in
> the future to where translations would be considered RC-level bugs.  You
> might read the thread to see our opinions on that.

We probably had a misunderstanding there. I certainly do not want and
did not write, that translation bugs should become RC stuff.

I wanted to mention that having stuff translated, especially when it
interacts with users is a major consideration for me.

So, the software *and the package* should use methods for making this
possible.

More precisely speaking, and just for giving an example, I hope that
someday using po-debconf will become mandatory in the distribution
(see #206684 for the first step).

So, yes, if this is adopted (206684 is just the first step-->make
debconf mandatory and recommend to use the gettexted variant), a
package prompting the user without (po-)debconf (or a similar tool but
there isn't another one) might have a RC bug raised against him.

But, of course, I absolutely do not want to have my 1292th BR for
"French debconf templates translation" be something else than tagged
as "i18n" when this tag will exist and certainly not RC

(time for boosting #114221, I think...)

This was for clearing up my pointI still think that the discussion
more or less lead nowhere unless we manage to continue it with a few
beers for tempering our feelings... ;-)

-- 

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

[Martin Quinson]

On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> 
> > > 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.
> 
> As I said above, which you apparently missed, I'm referring to NMU's in
> general.

No, I did not miss your point, but we (ie, almost everybody in the thread
beside you) are speaking of the special case of translation bug NMUing. I
also understood that you feel that such thing is a bad thing. 

What I still wait for is another solution around that particular problem.

If I understand correctly, you seem to say that packages with dormant
translation bugs should be orphaned or removed from the distribution. If so,
then *you* think that translation bugs are RC, don't you? On which other
argument do you want to orphan packages with dormant translation bugs when
other kinds of bugs are not sufficient to orphan the package? 

I do not think that translation is a sufficient issue to orphan the package,
even if the fact that having such simple fix not applied shows that the
maintainer either 1) does not know what to do with the patch 2) does not
trust the patch since he cannot check it 3) have so few interest in
translations that he does not bother dealing with the bug 4) is MIA, at
least temporarily.

I don't belive in 1. If you cannot handle a patch, then you shouldn't
maintain a package. No matter if it's uuencoded or not. It was said earlier
in the thread that the dormance of translation bugs was not a trust issue,
discarding 2. Moreover, that's what the debian-l10n-* lists are made for.

I have no problem with people falling in the 3rd category. Everybody has his
own center of interest. That's fine as long as translators can do their part
of the job. But if we cannot NMU such package, what can we do? 

Contrary to you, I have no problem either with MIA maintainers. We all have a
real life, and not tuning every day packages which are free of issues
(beside whishlist ones) is also ok for me.

I guess that most of the packages Christian NMUs are somewhere between 3 and
4. What do you propose to get these bugs integrated beside of NMUing and
raising the gravity of the bug, which we do not want to do?

> I'm starting to tire of this.  If you can't maintain the package you
> shouldn't be NMU'ing it.  It's really that simple.

Maybe you're tired of typing the same sentences with no argument in it?

Quoting the RM bits: "You should consider this perhaps your one and only
chance to get some fix you desperately need into sarge, whether it be to a
release-critical bug, an important bug, a normal bug, a minor bug, or in
many cases even a wishlist bug." 

The french translation team aims at providing a fully translated
installation, *including the package installations*. That's the sub-release
goal of our sub debian team. We only speak of using the opportunity offered
by the RM to do so.

> > > 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 ?
> 
> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

So, what do you think of people currently going through the RC bugs and mass
NMUing packages they do not intend to maintain afterward, just to fix
compilation bugs? I've the feeling that you strongly disagree with this
behaviour too, but I may be wrong.

> > 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.
> 
> You, again, didn't read the thread. 

Your attitude is kind of arrogant on that point. My broken english does not
prevent me to read the thread, which I did.

> No one said anything about
> threating to open RC bugs, etc, etc.  There was, however, a discussion
> about the possibility of changing the severity level at some point in
> the future to where translations would be considered RC-level bugs. 

And I did clearly state that it was not the case. 

The only explanation I have for you thinking that it was said is the
language barrier. Maybe Christian wrote a sentence in english which may
imply so under some native speaker analysis, *but it was not intended*.

Christian and I (and bunch of others) have the feeling that bugs providing a
translation should be trea

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

[David Weinehall]

On Mon, Aug 25, 2003 at 08:43:55AM +0200, Andreas Metzler wrote:
> Stephen Frost <[EMAIL PROTECTED]> wrote:
> > * Andreas Metzler ([EMAIL PROTECTED]) wrote:
> >> Parse error. I cannot see a connection between answer and question.
> 
> > Life's a beach.  There's all of one line in the developer's reference
> > which talks about your responsibilities when doing an NMU:
> > "Follow what happens, you're responsible for any bug that you introduced
> > with your NMU."  Now, this works fine when the official maintainer is
> > going to follow up; it doesn't work worth a damn if the official
> > maintainer isn't taking care of the package at all anymore.
> 
> Why? Neither the package, nor its quality nor its state of
> unmaintainedness has changed, it just has one (wishlist) bug less.

[snip]

Pah, let's require all maintainers to be able to fix all
translation-bugs on their own.  It should be a requirement to be fluent
in all nuances of all languages to be a maintainer.  Right?  I mean, you
must be able to fix any bug in the package just because you NMU
a new translation, so you better be able to fix any translation-bug if
you fix a memory-leak, right?


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

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

[Andreas Metzler]

Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Andreas Metzler ([EMAIL PROTECTED]) wrote:
>> Parse error. I cannot see a connection between answer and question.

> Life's a beach.  There's all of one line in the developer's reference
> which talks about your responsibilities when doing an NMU:
> "Follow what happens, you're responsible for any bug that you introduced
> with your NMU."  Now, this works fine when the official maintainer is
> going to follow up; it doesn't work worth a damn if the official
> maintainer isn't taking care of the package at all anymore.

Why? Neither the package, nor its quality nor its state of
unmaintainedness has changed, it just has one (wishlist) bug less.

> Prior to
> doing an NMU you tend to have a pretty good idea which is the case, or
> you should at least.

You'll still have the same pretty good idea about this fact after the
NMU.

>> [...]
>> > 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.
>> [...]
 
>> I've loosely followed the thread but your only argument in favour of
>> this statement seems to be that if people NMU'd to upgrade the
>> translation there will be an delay in us recognizing the package missing
>> a proper maintainer and orphaning or removing it.

>> I do not think that argument holds, an unmaintained package will show
>> other signs of negligance, and the qa people checking for unmaintained
>> packages know how to differ between NMU and maintainer upload.

> You've obviously not been paying very much attention at all then.
> You should have a pretty good idea if the package is unmaintained or
> not prior to doing an NMU.  If it's not then you're uploading a package
> which fixes some specific bug but leaves the package unmaintained.
> That's irresponsible.

Why? Because "there will be an delay in us recognizing the package
missing a proper maintainer and orphaning or removing it"?
   cu andreas

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

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> > binary-only uploads are clearly not the same.
> 
> Ah ? And why ? Translation changes do not interfer with the source code of
> the package neither.

Hummm. Technically speaking, it does.. :-). With the source code of
the packagenot with the upstream source code.

But, for instance, the debconf translation changes do interfere with
debian/control (for switch to po-debconf) and even sometimes with
debian/rules (when the maintainer does not use debhelper).

Pure translations, of course, interfere less with the "real" source
(debian/rules and maintainer scripts), but they may lead to strange
output when compiling the package (particularly if the translation is
incomplete).

This does just show again that translation NMU *also* require close
attention by the NMU'er, but as you and I already said ? ? ?this is
exactly what we're currently doing.. :-)

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

[Stephen Frost]

* Martin Quinson ([EMAIL PROTECTED]) wrote:
> On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> > 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.

Translations should not be special cased.  It's a new upload of the
package just like any other NMU.

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

As I said above, which you apparently missed, I'm referring to NMU's in
general.

> > > 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
> i18n issues.
> 
> > 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'm starting to tire of this.  If you can't maintain the package you
shouldn't be NMU'ing it.  It's really that simple.

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

Just about everyone else appears to feel all they should care about is
the changes they make in their NMU instead of actually caring about the
package and the distribution.  There's this feeling of "not my problem".

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

It'd just get in my way.  You're making generalizations where I've
already pointed out you can't make them.

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

That was later, as I recall, though I'm too tired of this crap to bother
looking for it explicitly.

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

You, again, didn't read the thread.  No one said anything about
threating to open RC bugs, etc, etc.  There was, however, a discussion
about the possibility of changing the severity level at some point in
the future to where translations would be considered RC-level bugs.  You
might read the thread to see our opinions on that.

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

Doing an NMU of a package you can't maintain is irresponsible.

> > You're i

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

[Stephen Frost]

* Andreas Metzler ([EMAIL PROTECTED]) wrote:
> Parse error. I cannot see a connection between answer and question.

Life's a beach.  There's all of one line in the developer's reference
which talks about your responsibilities when doing an NMU:
"Follow what happens, you're responsible for any bug that you introduced
with your NMU."  Now, this works fine when the official maintainer is
going to follow up; it doesn't work worth a damn if the official
maintainer isn't taking care of the package at all anymore.  Prior to
doing an NMU you tend to have a pretty good idea which is the case, or
you should at least.

> [...]
> > 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.
> [...]
> 
> I've loosely followed the thread but your only argument in favour of
> this statement seems to be that if people NMU'd to upgrade the
> translation there will be an delay in us recognizing the package missing
> a proper maintainer and orphaning or removing it.
> 
> I do not think that argument holds, an unmaintained package will show
> other signs of negligance, and the qa people checking for unmaintained
> packages know how to differ between NMU and maintainer upload.

You've obviously not been paying very much attention at all then.
You should have a pretty good idea if the package is unmaintained or
not prior to doing an NMU.  If it's not then you're uploading a package
which fixes some specific bug but leaves the package unmaintained.
That's irresponsible.

Stephen


pgp5hGTmX8DTM.pgp
Description: PGP signature

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

[Martin Quinson]

On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) 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
i18n issues.

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

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

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

[Andreas Metzler]

Stephen Frost <[EMAIL PROTECTED]> wrote:
[...]
>> > 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".

Parse error. I cannot see a connection between answer and question.

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

I've loosely followed the thread but your only argument in favour of
this statement seems to be that if people NMU'd to upgrade the
translation there will be an delay in us recognizing the package missing
a proper maintainer and orphaning or removing it.

I do not think that argument holds, an unmaintained package will show
other signs of negligance, and the qa people checking for unmaintained
packages know how to differ between NMU and maintainer upload.

I'd like to see an answer to
<[EMAIL PROTECTED]>, BTW.
   cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

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

[Stephen Frost]

* Martin Quinson ([EMAIL PROTECTED]) 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