[Rpm-maint] Planning for rpm 4.13.0 (-rc2)
pmatilai at laiskiainen.org
Sat Dec 10 09:18:59 UTC 2016
On 12/10/2016 01:46 AM, Gleb Fotengauer-Malinovskiy wrote:
> On Fri, Dec 09, 2016 at 06:24:02PM +0200, Panu Matilainen wrote:
>> On 10/17/2016 11:05 AM, Panu Matilainen wrote:
>>> On 10/16/2016 10:15 AM, Dmitry V. Levin wrote:
>>>> On Fri, Oct 14, 2016 at 04:33:00PM +0300, Panu Matilainen wrote:
>>>>> Hey folks,
>>>>> Time to get rpm 4.13.0 out of the door. But in order to do that, we'll
>>>>> need to cut -rc2 first, there's just too much change to jump right into
>>>>> The idea is to get -rc2 out next week (ie by Oct 21st at latest). If all
>>>>> goes well we'll just rename that to -final in a few weeks time, if all
>>>>> goes to hell we'll just have another -rc. Which I really, really dont
>>>>> want to happen. So what I've planned for -rc2 is this rather
>>>>> conservative cherry-picks from git master on top of the 4.13.x branch:
>>>>> Anyway, the list above is not set in stone, otherwise there'd be little
>>>>> point in posting it here. If you think something absolutely critical is
>>>>> missing from that list, or that something should not be there, now is
>>>>> the time to speak up.
>>>> Please include rpmdb.c fixes (commits 4c6e51e2 and e5d3b9f6), they are
>>>> essential for apt-rpm.
>>> Request noted, but remember this is an ages old runtime bug, finally
>>> fixed. Whether it gets fixed or not does not affect eg package or
>>> API/ABI compatibility, so it can just as well be fixed in 4.13.1.
>> So... in one of my weak moments I ended up letting these patches in
>> 4.13.0 against my own guidelines and here's my reward: commit 4c6e51e2
>> breaks cleaning up the locks on ctrl-c and so we have a wholly unwanted
>> and unnecessary regression in 4.13.0. Yeah it doesn't double free
>> because it doesn't free at all, at least in this case - yay.
> Oh, I'm sorry.
> I think, my commits both break cleanup of database locks. :(
Possibly, I haven't looked that closely yet.
Note that I'm not angry at *you*, apologies if my email from yesterday
seemed that way. To heir is human, mistakes and regressions happen all
the time and it's not the end of the world, that's what the development
tree is there for.
I'm fuming at people (not you) requesting what from upstream perspective
was clearly untried code to be included in a stable release against
quite specific instructions regarding that particular release. However
you don't see this problem if private BDB environment is used in the
rpmdb (eg Suse does this), I don't know if that's the case with AltLinux
but that would be a reasonable excuse to think everything is ok with the
I'm fuming because clearly none of the reviewers and testers (including
myself) thought to actually test this patch doesn't break the sole
reason the murky piece of code is there for to begin with: database lock
freeing on ctrl-c with shared BDB environment.
In particular I'm fuming at myself for letting untried code touching a
sensitive and difficult piece of code into a stable tree when I
certainly should know better by now.
So ultimately I'm just very p****ed at myself and venting it out in
public so come next round of stable releases, I *might* remember this
incident and think again.
Again, apologies if it sounded like I was mad at you, should've counted
to ten a few more times before hitting send yesterday.
- Panu -
More information about the Rpm-maint