On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford <firstname.lastname@example.org> wrote:
> > 2) 9 times out of 10 there was very little data put into the ticket.
> Multiple options here. Kick back incomplete tickets, or the better
> option IMNSHO, run rpmdiff runs between the package currently in the
> compose and the one in testing to check for various failures and
> require the developer to justify failures.
Which rpmdiff are we talking about here?
The free/included in fedora one is not that great... it gives you files
and deps that changed, but that doesn't help you see what changed in
> > 3) releng folks were often not the best people to decide whether a
> > change was "too risky"
> The rpmdiff option above would help with this.
So, I run it on xfwm4 updates:
rpmdiff xfwm4-4.8.1-2.fc15.x86_64.rpm xfwm4-4.8.1-3.fc16.x86_64.rpm
removed REQUIRES libpng12.so.0()(64bit)
removed PROVIDES xfwm4(x86-64) = 4.8.1-2.fc15
added PROVIDES xfwm4(x86-64) = 4.8.1-3.fc16
...all the doc files have different timestamp...
What does that help me with?
> > 4) There was no easy way to get at the package and assess its
> > stability.
> Using bodhi instead of trac solves this, no?
well, not bodhi, but a repo like updates-testing, yeah.
> > I think there were more issues, but those come to mind first. We
> > decided it was best instead to make a repository out of proposed
> > changes,
> But in practice that's not really what updates-testing on the early
> branched release really is. It's a repo all right, but not of
> proposed changes, it's a repo of packages, and getting to the actual
> changes versus the final package would require installing the current
> source rpm, the new source rpm, then doing a manual inspection for
> changes. An automated rpmdiff run would be a *far* superior means of
> presenting the proposed changes to the community.
I'd love to see something more detailed from rpmdiff.
devel mailing list