Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
Kevin Fenzi
kevin at scrye.com
Tue Sep 20 20:59:46 UTC 2011
On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford <dledford at redhat.com> wrote:
...snip...
>
> > 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
them...
>
> > 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
S.5.......T /usr/bin/xfwm4
S.5.......T /usr/bin/xfwm4-settings
S.5.......T /usr/bin/xfwm4-tweaks-settings
S.5.......T /usr/bin/xfwm4-workspace-settings
..........T /usr/lib64/xfce4/xfwm4
S.5.......T /usr/lib64/xfce4/xfwm4/helper-dialog
...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. ;)
kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110920/9591cf18/attachment.bin
More information about the devel
mailing list