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

Re: Hinting my packages in :)



Marc 'HE' Brockschmidt wrote:
> Limited time. You didn't have the time to fix the address earlier, we
> don't have the time to fix that for you.

This reasoning is rediculous arbitrariness for me, sorry.

Isn't there any release manager around which is payed to do release
work? Maybe he could invest a few precious minutes to make a favour to
the previous maintainer (Graham), to not get bugged about the package
anymore while Etch life-time.

(and just for the records: When they were orphaned, I took all three
packages over bevor the next dinstall happened, so from my point of
view, there was not a possibility to do it faster.)

>>>>   * dahb-html 3.1.2.15-1
>>>>     this is a new upstream release of an online-book, should be
>>>>     no problem to hint this one in :)
>>> he@ries:~$ debdiff /org/ftp.debian.org/ftp/pool/non-free/d/dahb-html/dahb-html_3.1.2.1{4,5}*.dsc | wc -l
>>> 17876
>>>
>>> I don't think so.
>> Why? This book has updated html text pages - no code, no debian/* changes.
> 
> Because freezing means "No new upstream versions". There is a point when
> we only address bugs. I don't intend to make exceptions for "some
> things", because everyone will try to argue that their package needs an
> exception too.

So you allow pure l10n updates, but not if it's the same but labeled as
a new upstream release of a documentation only package?

Besides that dahb-html is already a valid candidate as of today (10 days
old of 10 days), and hence it would entered today when there wouldn't be
etch frozen today, this sounds not logical to me.

Anyway, if you insist on it - your the master, I (and the users) have to
accept that and live with an outdated package then, bummer.

(Note: the upstream changes are particulary about the Etch release)

>>>> ...and there are a few packages of mine where I suggest to hint them
>>>> into testing...
>>>>
>>>>   * dwm 2.6-1 and dwm-tools 4
>>>>     upstream has a extremous 'release often' policy, each minor fix
>>>>     gets a new upstream version. those fixes are simple, but important
>>>>     (e.g. for utf)
>>> No, until you show a bug.
>> Does that mean that I have now to go through the upstream changelog, and
>> issue 3 or 4 RC bugs against the dwm package for etch? Or do we
>> knowingly ship dwm 2.1?
> 
> I've went through the upstream changelog, didn't find something really
> important, asked someone using dwm as Window Manager if there were
> problems and then decided that "no new upstream release" really means
> "no new upstream release".

The dwm user you've asked must then not use UTF in his locales, because
UTF fonts are broken with dwm before 2.6 (fix is 12 lines long, same
with all the other fixes, they're trivial).

Do I need to backport this and the other changes then, including them
into a 2.1 testing upload, so that the upstream version is not bumped
and we can keep your rule about 'no new upstrem release', or do you
suggest to not fix these bugs?

-- 
Address:        Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:          daniel.baumann@panthera-systems.net
Internet:       http://people.panthera-systems.net/~daniel-baumann/



Reply to: