rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)

[Michael Schwendt]

On Mon, 23 Nov 2009 10:56:58 -0500 (EST), Seth wrote:

> 
> 
> On Mon, 23 Nov 2009, Michael Schwendt wrote:
> 
> > On Mon, 23 Nov 2009 15:04:49 +0100, Christoph wrote:
> >
> >> Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt:
> >>> On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote:
> >>>
> >>>> When two builds of the same version are done on the same day, the
> >>>> rawhide report screws up the order of the changelog entries:
> >>>>
> >>>> Can this be fixed please?
> >>>
> >>> See Yum (yum-utils) upstream tickets #6 and #7 for the background. One
> >>> part of the fix will require a hack in the handling of repo metadata
> >>> stored in SQLite tables.
> >>
> >> Thanks for the info, Michael.
> >> Obviously it's not so trivial.
> >
> > Well, somebody could still apply my patch attached to #7. It's a year
> > old and still without a reply. It would print the missing changelog
> > entries, which is what the ticket is about.
> >
> > | repodiff misses changelog entries (corner-case)
> > | http://yum.baseurl.org/ticket/7
> 
> I've replied a bunch of times and I offered you access to commit it 
> yourself. You never responded.

Do I need to repeat myself again and again that [and why] I don't want to
maintain repoclosure? I've told you that at least once, and we have never
talked specifically about commit access to repodiff. Not a year ago, not
in tickets #7 or #6, and not recently either. Perhaps with a comment (in
Oct 2009, months later) such as

  https://bugzilla.redhat.com/521621#c1

in the context of repoclosure (!) again, you meant to cover repodiff,
too. If that's true, you haven't made that clear. I realise that both
repoclosure and repodiff belong into "yum-utils", but hey, I have not
asked for commit access to either one. How hard can it be to accept a
patch or reject it with a brief comment?

Btw: The comment on #6 (not by you, but by jlaska, was mostly negative
even, which is quite the opposite of offering commit access to that tool.
The comment claimed my tested patch would be wrong - not true, it is tons
better than the broken reverse'n'sort implementation in createrepo+repodiff
that just doesn't work as demonstrated by the rawhide report for a long
time and even broke repoview. Compare that with the old Fedora Extras
build report which still runs and runs and runs at RPM Fusion without such
errors).