Re: NMUs applying sleeping wishlist bugs about translation (was something else)
On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> * Martin Quinson (martin.quinson@tuxfamily.org) 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 treated as normal bugs, but we agreed on not forcing
the debian community to it until there was a consensus on that. There is no
point to use that inexistant point against translators.
> You might read the thread to see our opinions on that.
So could you. ;)
> > No, 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.
>
> That's a fine goal.
Thanks.
> No, we don't agree on the responsabilities of people who do NMUs. I
> would have them be more responsible than you, thus giving packages which
> have been let languish a chance to either be maintained or removed.
Again, what are you thinking of people currently mass NMUing RC bugs to fix
compilation issues and leave the package when they compile fine on one more
architecture or one more compiler?
> > > binary-only uploads are clearly not the same.
> >
> > Ah ? And why ? Translation changes do not interfer with the source code of
> > the package neither.
>
> There is a clear distinction between a source upload and a binary-only
> upload. One changes the source, the other doesn't. Your claim that
> translations don't change the source is false.
They do produce a change in the diff.gz, but they do not change the final
binary (only adding files for debconf use in this particular point, or
mucking under /usr/share/locale/ in the more general case). So, they will
not introduce unrelated bugs. For sure.
> > 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.
>
> I don't know that I would approve of such a method. I'd have to think
> on it more. I don't consider it a part of this discussion, however.
Sure. This is another part of the general issue "how to get translation
integrated in Debian". Please, if you have some more time, think about this,
and tell me before we even start think about implementing such solution what
you would not like in it, to avoid both of us long typing seances in the
future :)
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.
Bye, Mt.
--
use Mail::Signature;
$sig = Mail::Signature->new;
print $sig->random;
Reply to: