Hi, On Sat, Jul 21, 2012 at 09:56:24PM +0200, Guillem Jover wrote: > On Wed, 2012-06-20 at 09:42:18 +0100, Neil McGovern wrote: > > Advancing that as much as you can would certainly be useful to catch any > > errors, and to ensure translators get a chance to contribute. > > So, the upload happened few days later than planned, but still before > the freeze deadline.
ITYM the day of the freeze, 10 days later...
> But because there were posterior uploads to fix
> regressions, RC bugs and translation updates the automatic freeze
> exception does not apply anymore.
>
That would be correct, yes. It is only versions that are in unstable at
the time that get an unblock.
> The way I understood the freeze (as any feature freeze) was that code
> with new features on unstable at the time of the freeze would go in
> (JFTR there's been no new features added afterwards), even if they'd
> require to review the subsequent changes and update the version in
> the unblock.
Um, no. It's not a feature freeze. It's a Debian freeze, as has been for
the past 8 or so years. This means that someone on the release team has
to manually review the patchset.
> It could have happened that those regressions could have been spotted
> instead after the version would have migrated to testing, or
> regressions for the version in testing still be discovered, so I don't
> see the big difference really.
>
Ah, perhaps this is the confusion. The difference is the amount of time
it will take the release team to manually review every patch set.
> Just to clarify, because it might have seemed otherwise in my mail to
> the unblock request, personally I don't have any problem per se with a
> whole review of the diff between the version in testing and the one in
> unstable. And even way way longer than usual delay in transitioning the
> package from unstable, say at least one more month or more, to catch
> any other possible regression if there's fear of that.
>
Yes, the issue is that the release team need to manually review the
patch set, not you.
> But then I don't think having to argue over every and each change
> in 1.16.5, or having to prepare releases through t-p-u, with the
> implication of needing to reissue a call for translators is a good
> way of spending our collective time.
Well, it requires much less work for the release team, who no longer
need to manually review the patch set.
> And while it's not like we are releasing immediately anyway, doing the
> above just implies more work for everyone, which certainly does not
> help speeding up the release process.
I've started to see this in a couple of places now. Let me be as clear
as possible in case anyone hasn't noticed.
*************************************
*** WE HAVE FROZEN DEBIAN WHEEZY. ***
*************************************
This does not mean you can upload random stuff to the archive because
the release is "ages away". This sort of wooly thinking helps generate a
self fulfilling prophecy that delays the release and harms Debian
overall. It means that the release team need to spend a lot of manual
time reviewing the patch sets and thus can't concentrate on RC bugs.
> But then if you still disagree and require us to go through the stuff
> in the above paragraphs, then I think I'll just take the blame for my
> misunderstanding, notify translators they should stop bothering,
> pofusely apologize to them, and very regretably leave the IMO worse
> 1.16.4.3 version for wheezy, and call it a day.
That is of course, your perogative. However, if you could kindly prepare
a patchset between 1.16.5 and whatever you want to migrate, with all the
translation and documentation changes stripped out, lets see how big
that is.
Thanks,
Neil
--
signature.asc
Description: Digital signature
