Re: Freeze Exceptions for libti*, TiLP, GFM and TilEm
Hello,
>> I should've done this earlier, but better late than never, right?
>
> Not really. There are time limits and they passed quite a long time ago
> now...after a considerable period of notice of the time limits
> themselves...
In the end, it was still good, because now I understand a bit more
about the freeze.
>> (I was under the impression that the packages must enter unstable
>> before considering any wheezy/testing exceptions.)
>
> All the packages you mention are at the same version in testing and
> unstable currently - if you are proposing updated packages to be
> uploaded to unstable then, yes, the packages must be already in
> unstable and without fresh RC bugs before considering a freeze
> exception.
Yup.
> A release freeze is NOT the right time to test new upstream versions of
> packages! All packages for consideration in a Debian stable release
> must be allowed time for testing within Debian before the release.
Yeah, I did not consider the time to testing any breakages, etc. in Debian.
> New packages do not meet the criteria for freeze exceptions.
>
> 1. fixes for release critical bugs (i.e., bugs of severity critical,
> grave, and serious) in all packages;
>
> 2. changes for release goals, if they are not invasive;
>
> 3. fixes for severity: important bugs in packages of priority: optional
> or extra, only when this can be done via unstable;
>
> 4. translation updates and documentation fixes; pre-approved fixes;
>
> 5. as above, important changes that the maintainer feels are needed
> before release.
>
> http://release.debian.org/wheezy/freeze_policy.html
My intent was based on #5 - the current package(s), as they stand, are
rather unusable.
>> libticonv:
>> * Fixes #686635 and #678872. The former is a copyright bug that has
>> been fixed by a NMU, which provides a partial fix that is remedied by
>> my update. #678872 is an ITA.
>
> If #686635 is only a partial fix, re-open the bug.
Will do.
>> libticables:
>> * This one fixes a LOT of bugs:
>
> None of which are release critical for Debian.
Ah - I originally thought that FTBFS was considered RC.
> ITA bugs are not release critical.
Yeah, I knew that.
>> I believe that these packages are very beneficial for the
>> Debian/Ubuntu/Mint TI Linux community, and have significant demand.
>
> But none have had any testing in Debian and the opportunity for these
> packages to migrate into Wheezy has been missed.
Unfortunately...
> So the packages are not even ready for testing in unstable... just how
> long is Debian expected to wait for these updates when the window for
> these uploads closed 3 months ago already?
> Doesn't look as if any of these prospective uploads meet any of the
> criteria for a freeze exception.
Alright, understood.
> The packages have waited this long for an update, do the upload to
> unstable after the release and then consider a backport. In the
> meantime, please consider working on some of the existing RC bugs to
> help get the release done. That way, everyone gets what they want
> quickly.
Well, if I have time and motivation. (Currently the only reason I can
approach you with these packages is because I've hired a helper to
work on the packaging with me...) Nevertheless, I will certainly work
on fixing the aforementioned copyright bug.
I've only started doing packaging work for these packages in May, very
much close to the deadline.
Despite some time I had in the summer to work on these packages,
external circumstances prevented me from completing the work on time.
Nevertheless, I understand that you can't allow these kind of
exceptions, since _everyone_ will probably be asking for such an
exception, and for bigger packages too, which would prevent a release
from happening.
Thanks for your time in helping me understand the freeze unblock
criteria! One last question...
For backports, would I ask end users to add that repo once the release
occurs? And backports will NOT ever migrate packages to stable
(wheezy), I would assume?
Thanks!
Albert
Reply to: