--- Begin Message ---
On 2014-10-30 11:11, Ricardo Mones wrote:
> Hi Niels,
>
> On Wed, Oct 29, 2014 at 10:42:27PM +0100, Niels Thykier wrote:
>> [...]
>>
>> We did this because we learned from a painful experience with Wheezy.
>> Things in unstable do not always migrate when people expect it too.
>> Yours probably would, but we had far too many issues with it last release.
>
> Well, 3.11.0 was going to be the desired version for jessie and would
> have migrate without problem. Unfortunately some addition in that release
> (appdata) wasn't as tested as expected and caused some undesired efect,
> so upstream decided to rollback those changes and make a quick bugfix
> release:
> http://lists.claws-mail.org/pipermail/devel/2014-October/001320.html
>
> To be completely fair: after knowing the problems I myself requested
> also that release, because I thought that was the case the pre-freeze
> unblocks were made for.
>
I have no doubt that
> If I had knew beforehand this you're telling me now I wouldn't have acted
> that way. And I'm sorry, but I was unable to conclude that from the
> announce message (not your fault, of course).
>
I understand that. The announcement message and the freeze policy is
generally not optimised for this brief time window, where we transition
from "regular rules" to "freeze rules". And I readily admit that I
prefer to err on the side of "freeze rules" rather than "regular rules".
I do not do this to be bureaucratic for the sake of being bureaucratic
but rather to preserve myself the rest of the team. From experience
(with Wheezy), we get a lot request, of which a good share of them turns
out to be people not reading the freeze rules at all (or possibly hoping
for a more liberal interpretation of them).
>> Then the premise would have been entirely different and I would have a
>> different basis for my decisions. I might have advised you to let
>> 3.10.4-1 migrate as it with the promise of accepting the diff if it
>> migrated (assuming X was not a "major" issue), or said "ok, we will take
>> it 3.11.1-1 immediately and we will unblock it now".
>
> Well, yes, unfortunately I don't have a crystal ball and cannot foresee
> if a upstream release is going to cause problems. Since you have mixed
> some versions above, and just to make it clear:
>
> [...]
Thanks for the clarification - I clearly screwed up those numbers.
Obviously, I meant I might have advised you to let 3.11.0-1 migrate.
>
> I could have let 3.11.0 migrate, sure. But also considered there was no need
> to expose testing users to undesired upstream changes if simply asking for
> a age reduction was going to fix that. Clearly I failed to understand the
> side effects of the request.
>
> […]
Right - that is definitely a valid reason.
>>> Or do you really mean debdiff between 3.11.0-1 and 3.11.1-1?
>>>
>>
>> No, I truly mean the debdiff between 3.10.4-1 and 3.11.1-1.
>
> Ok, don't expect miracles, since there's a new implementation of RSSyl
> plugin between these two releases. Anyway upstream author has take years
> (literally) to merge this, so I'm confident the new implementation works
> pretty well. No bug reported upstream so far helps too.
>
> Some of the changes are also because added missing license headers, but
> I think most of them (caused by Makefile.am files) are filtered out.
>
> Summary of remaining files is (full diff with diffstat attached):
>
> 210 files changed, 9403 insertions(+), 5898 deletions(-)
>
> Detail of exclusions:
>
> [...]
>
Ugh, that is still pretty big... >.> I read some of it, but admittedly I
had to forfeit on the RSSyl plugin. For reference, feel free to filter
out completely auto-generated files (e.g. configure or the files
generated from flex/bison)
> If this is not OK for testing, please tell me how to proceeed, since
> current 3.10.1-4 in testing should be replaced by some patched version
> not vulnerable to poodle or removed.
>
> Thanks in advance,
>
I should probably have realised earlier that "SSL v3 removal" was a
"POODLE fix" - I have decided to give it an ageing of 5 days, since we
are dealing with a security fix.
Assuming the mips build completes successfully, it should be able to
migrate in a little over 48 hours from now.
~Niels
--- End Message ---