Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

[Doug Ledford]

----- 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 at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford