[Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Dmitry V. Levin]

On Sat, Dec 10, 2016 at 11:18:59AM +0200, Panu Matilainen wrote:
> 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:
> >>>>Hi,
> >>>>
> >>>>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
> >>>>>final.
> >>>>>
> >>>>>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 
> patch.

Well, feel free to shoot the messenger^W^W^W blame me for the request
if it helps. :)


-- 
ldv