----- Original Message -----
This is essentially what we had a while ago, only with trac tickets
instead of bodhi requests.
Bodhi is definitely a better place to track this stuff, regardless of how decisions are
made.
There were a couple of problems with
this.
1) Nowhere near enough releng folks to properly review all the
tickets.
Fair enough.
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.
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.
4) There was no easy way to get at the package and assess its
stability.
Using bodhi instead of trac solves this, no?
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.
and let your packaging peers decide whether or not the
update was safe enough to go into the release,
But they can't, not really. For instance, a proventester may install my mdadm
package, but if they don't have a raid array, they can't decide anything. Where
as if they had access to the code diffs and could tell that all I did was change a typo in
the udev rules file, and verify for themselves via code inspection that the code as it
stands in the repo can't work and the fix should work, then they could make an
educated contribution. Because the testing repo doesn't really present changes, but
only a final product, there is no possibility for my peers to look at my changes and say
"Yeah, that's should be a safe change, let it in, and if it breaks then we'll
fix it". So the judgement call that I mentioned in my previous email is taken
entirely out of the loop, and there is no ability for my peers to make any contribution to
whether or not a package should be allowed in *except* unit testing, there is no ability
for them to easily do an actual analysis of the changes and make an engineering decision
versus a QA decision.
thus we have bodhi
and updates-testing as a gateway to get into the release.
It's a gateway, I just don't think it serves as useful a purpose as it was
intended to.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford