----- 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 ma
 ke 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 <dledf...@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to